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Item  20.  Abstract  (Continued) 


to  operate  upon  the  data  base  produced  in  Task  1 , and  constrained  by  the 
preliminary  requirements  established  in  Task  2.  The  preliminary  system 
concept  described  in  this  Task  3 report  will  be  further  exercised  and  re- 
fined through  the  performance  and  cost  effectiveness  tradeoffs  of  Tasks  4 
and  5. 

\ 


\ 


TASK  3 REPORT  (CDRL  A003) 

PRELIMINARY  NTIP  SYSTEM  CONCEPT 
AND  ALTERNATIVE  CONFIGURATIONS 

NAVY  TECHNICAL  INFORMATION  PRESENTATION  PROGRAM 

Submitted  to 

David  VV,  Taylor  Naval  Ship  R&D  Center  (Code  1803) 

In  Response  to 
Contract  N00600-76-C-1352 

by 

Hughes  Aircraft  Company 
Ground  Systems  Group 
Fullerton,  California 


27  January  1978 
FR  77-12-150 


Approved  for  Public  Release;  Distribution  Unlimited 


I 


FOREWORD 


Hughes  Ground  Systems  Group  is  pleased  to  submit  this  Task  3 
Report,  identified  as  CDRL  Item  A003,  to  the  David  W.  Taylor  Naval 
Ship  Research  and  Development  Center  (DTNSRDC),  Bethesda,  Maryland 
in  accordance  with  Contract  N00600-76-C-1352  for  the  Navy  Technical 
Information  Presentation  Program  (NTIPP).  This  contract  is  under  the 
technical  management  of  Mr.  S.C.  Rainey  and  Mr.  J.J.  Fuller,  both  of 
DTNSRDC  Code  1803. 

Performing  organization  personnel  who  participated  in  the 
Task  3 effort  and  in  the  preparation  of  this  report  include  the  following 
individuals: 

J.E.  Connell 
J.J.  Goldberg 

V. L.  Kefauver 
J.W.  Kelsey 
A.  Laicato 
C.E.  Marvin 
H.A.  McDougal 
N.S.  Merlo 
G.L.  Sietsema 
R.C.  Sisman 
J.R.  Tracey 

W. N.  Waldau 

V. C.  Westgate 

W. L.  Taylor 


TABLE  OF  CONTENTS 


SECTION  S - EXECUTIVE  SUMMARY 

Subsection  S.l  - NTIPS  Objectives 

5.1.1  The  Navy  TM  Problem  Involves  Technical,  Human  Factors, 

and  Procedural  Elements  S-0 

5.1. 2 The  Achievement  of  the  NTIP  Program  Goals  Requires  a 

Definitive  Preliminary  Concept  S-1 

Subsection  S.2  - System  Concept 

5.2.1  Overview  of  Preliminary  NTIP  System  Concept  S-2 

5.2.2  TM  Acquisition  Must  Insure  that  Technical  Information  is 

Properly  Defined,  Specified,  and  Procured S-3 

5.2. 3 The  Approach  to  Content  Generation  Aims  to  Reduce  Errors 

and  Increase  Efficiency  in  the  TM  Writing  Process S-4 

5.2. 4 The  Key  Feature  of  the  Publishing  Subsystem  is  the  Computerized 

Production  Method S-5 

5.2.5  Distribution  Control  is  Computerized  to  get  the  Right  TM/Update 

to  the  Right  User  S-6 

5.2.6  NTIPS  Management  Subsystem  Provides  Control  at  Both  "Corporate" 

and  "Division"  Levels S-7 

Subsection  S.3  - System  Issues 

5.3.1  Plans  for  System  Evaluation  and  Cost  Analysis  S-8 

SECTION  1 - INTRODUCTION  AND  METHODOLOGY 

1.1  Objectives  of  Task  3 1-0 

1.2  Approach  to  Task  3;  Preliminary  NTIP  System  Concept  and 

Alternatives  1-2 

SECTION  2 - NTIPS  REQUIREMENTS 

2.1  Program  Goals  and  System-Level  Requirements 2-0 

2.2  Description  of  System  Functional  Requirements 2-6 

2.3  Description  of  System  Operational  Sequence 2-12 

SECTION  3 - PRELIMINARY  NTIP  SYSTEM  CONCEPT 

3.1  Description  of  Preliminary  NTIP  System  Concept 3-0 

3.2  Technical  Approach  to  TM  Acquisition  Subsystem 3-6 

3.3  Technical  Approach  to  Content  Generation  Subsystem 3-8 

3.4  Developing  the  Detailed  TM  Design 3-10 

3.5  Establishing  a Relationship  Between  TMs  and  Training 3-12 

3.6  Technical  Approach  to  Publishing  Subsystem 3-16 

3.7  Considerations  in  Selecting  User  Media  3-20 

3.8  Use  of  Media  in  the  User  Community 3-24 

3.9  Technical  Approach  to  Distribution  Subsystem  3-26 

3.10  Technical  Approach  to  Management  Subsystem 3-30 

3.11  Method  for  Updating  Technical  Manuals 3-32 

SECTION  4 - SUBSYSTEM  PRELIMINARY  CONCEPTS  AND  ALTERNATIVES 

Subsection  4.1  - TM  Acquisition  Subsystem 

4.1.1  Description  of  TM  Acquisition  Subsystem 4-0 

4.1.2  Description  of  User-Data  Match  Function  4-2 

4.1.3  Description  of  TM  Specification  Function  4-6 


TABLE  OF  CONTENTS  (Continued) 


4.1. 3.1  Description  of  Technical  Content  Specifications  4-10 

4. 1.3.2  Description  of  Presentation  Technique  Specifications 4-14 

4. 1.3.3  Preliminary  Concept  of  Readability  for  NTIPS 4-16 

4. 1.3.4  Considerations  for  Setting  the  RGL  Requirements 4-20 

4. 1.3. 5 Description  of  Access  Specifications 4-22 

4. 1.3.6  Description  of  Publishing  Processes  Specifications 4-24 

4. 1.3.7  Description  of  Quality  Control  Specifications  4-26 

4.1.4  Description  of  the  TM  Procurement  Function 4-28 

Subsection  4.2  - Content  Generation  Subsystem 

4.2.1  Description  of  Content  Generation  Subsystem 4-30 

4.2.2  Description  of  Engineering/Manufacturing  Data  Base 4-34 

4.2.3  Description  of  Estimating  Function 4-38 

4.2.4  Description  of  Product  Planning  Subfunction  4-42 

4.2.5  Description  of  the  Operational  Planning  Subfunction 4-46 

4.2.6  Description  of  Writing  Function 4-50 

4.2.7  Purpose  and  Description  of  the  TM  Development  Guide 4-54 

4.2.8  NTIPS  T, VI  Writers  Guide 4-56 

Subsection  4.3  - Publishing  Subsystem 

4.3.1  Description  of  Publishing  Subsystem 4-60 

4.3.2  Description  of  Digital  Production  Function 4-64 

4.3.3  Digital  Production  Function  Alternatives 4-68 

4.3.4  Description  of  Mastering,  Replication,  and  TM  Supply 

Functions 4-72 

4.3.5  Mastering,  Replication,  and  TM  Supply  Function  Alternatives  ....  4-76 

Subsection  4.4  - Distribution  Subsystem 

4.4.1  Description  of  Distribution  Subsystem  Preliminary  Concept 4-78 

4.4.2  Description  of  Initial  Distribution  Control  Function 4-80 

4.4.3  Description  of  Initial  Distribution  Control  Function 

Alternatives 4-84 

4.4.4  Description  of  the  Resupply  Function 4-84 

4.4.5  Description  of  Resupply  Function  Alternatives 4-88 

4.4.6  Description  of  the  Archive  Function 4-90 

4.4.7  Digital  Archive  Technology  Considerations 4-92 

4.4.8  Description  of  Archive  Function  Alternatives 4-84 

Subsection  4.5  - Management  Subsystem 

4.5.1  Overview  of  Management  Subsystem  Preliminary  Concept  4-96 

4.5.2  Description  of  the  NTIP  System  Management  Function 4-98 

4.5.3  Description  of  NTIPS  Operations  Management  Function  4-100 

4.5.4  Support  of  Operations  through  the  NTIPS  Management 

Information  System  (MIS) 4-102 

4.5.5  Description  of  the  Centralized  NTIPS  Management  Subsystem 

Alternative 4-104 

4.5.6  Description  of  Decentralized  NTIPS  Management  Subsystem 

Alternative 4-106 

SECTION  5 - APPROACH  TO  TASKS  4 AND  5 

5.1  Plans  for  Performance  Evaluations  of  Preliminary  Concept  and 

Alternatives 5-0 

5.2  Plans  for  NTIPS  Cost  Analysis 5-2 


IV 


TABLE  OF  CONTENTS  (Continued) 


APPENDIX  A - REFERENCES A-1 

APPENDIX  B - GLOSSARY  OF  ABBREVIATIONS  AND  ACRONYMS B-1 

APPENDIX  C - DEFINITIONS  OF  NTIPP  TERMS C-1 

APPENDIX  D - DESCRIPTION  OF  SYSTEM  OPERATIONAL  SEQUENCE D-1 


LIST  OF  FIGURES 


Figure  Title  Page 

1- 1  Relationship  of  Task  3 to  Overall  NTIPP  Effort 1-1 

2- 1  NTIPS  Functional  Block  Diagram 2-11 

2- 2  Representative  Section  of  Operational  Sequence  Diagram  for  TM 

Development  2-13 

3- 1  Preliminary  NTIP  System  Concept 3-5 

3-2  Detailed  TM  Design 3-11 

3-3  TM  Update  System  for  Hardware-Related  Updates 3-33 

3- 4  TM  Update  and  Feedback  System  for  Nonhardware-Related  Updates 3-35 

4- 1  TM  Acquisition  Subsystem 4-1 

4-2  Procedure  for  Using  the  Matrices  in  the  User-Data  Match  Model 4-3 

4-3  TM  Specification  Evolution  Process 4-7 

4-4  Proposed  Technical  Content  Specification  Modules 4-11 

4-5  Ranking  of  Navy  Ratings  by  GCT  Scores  and  Equivalent  RGL  Scores 4-21 

4-6  TM  Procurement  Function  Organizational  Alternatives 4-29 

4-7  Content  Generation  Subsystem 4-31 

4-8  Estimating  Function 4-41 

4-9  NTIPS  IToduct  Planning  Subfunction 4-45 

4 10  NTIPS  Operational  Planning  Subfunction 4-49 

4-11  NTIPS  Preliminary  Concept  for  Writing  4-53 

4-12  Approach  to  TM  Writers  Guide  4-57 

4-13  Publishing  Subsystem 4-61 

4-14  Subfunctions  of  the  Digital  Production  Function  4-65 

4-15  Mastering,  Replication,  and  TM  Supply  Functions  4-73 

4-16  Distribution  Subsystem  4-79 

4-17  Control  of  TM  Distribution 4-81 

4-18  Comparison  of  Centralized  and  Decentralized  Initial  Distribution 

Control  Function  4-83 

4-19  The  Resupply  Preliminary  Concept 4-87 

4-20  The  Resupply  Function  in  a Digital  Environment 4-89 

4-21  NTIPS  Archive  Function  4-91 

4-22  Alternative  Organizational  Placements  of  the  Archive  Function 4-95 

4-23  The  NTIPS  Management  Subsystem  4-97 

4-24  NTIPS  Management  Information  System 4-103 

4-25  Centralized  Management  Structure  Comparison  4-105 


LIST  OF  FIGURES  (Continued)  J 


Figure  Title 

4- 26  Decentralized  Management  Structure  Comparison 4-107 

5- 1  Performance  Evaluation  Process  5-1 

5-2  Cost  Analysis  Reporting  Matrix 5-3 

D-1  NTIPS  Functional  Sequence  Diagram  D"2 

D-2  General  NTIPS  Operational  Sequence  Diagram D-5 

D-3  Operational  Sequence  Diagram  D"7 


LIST  OF  TABLES 


Table  Title  Page 

2-1  Impact  of  NTIP  Progi  am  Goals  on  System  Requirements 2-1 

2- 2  Current  Volume  of  Navy  Technical  Manuals 2-3 

3- 1  Approach  to  TM  Acquisition 3-7 

3-2  Content  Generation  Key  Problems  and  Solutions 3-9 

3-3  Matrix  Showing  Possible  Assignment  of  Task-Related  Factors  of 

Training/Technical  Manual  Categories  3-13 

3-4  NTIPS  Publishing  Approach  3-17 

3-5  Implications  of  Media  Selection 3-21 

3-6  Usability  of  Media  in  the  User  Community  3-25 

3-7  NTIPS  Approaches  to  Problems  in  Distribution  3-27 

3- 8  Approach  to  NTIPS  Management  3-31 

4- 1  Typical  Technical  Content  Module  Selections  4-13 

4-2  Proposed  Presentation  Technique  Specification  Modules 4-15 

4-3  Candidate  Readability  Formulas  4-17 

4-4  Features  of  Readability  Concept  4-19 

4-5  Proposed  TM  Access  Specification  Modules 4-23 

4-6  Proposed  Publishing  Process  Specification  Modules  4-25 

4-7  Proposed  Quality  Coritrol  Specification  Modules  4-27 

4-8  NTIPS  Engineering  Manufacturing  Data  Base  Characteristics 4-37 

4-9  TM  Development  Guide  as  an  Aid  to  TM  Engineer 4-55 

4-10  Methodology  Needed  for  Candidate  Media  in  Publishing  Functions 4-63 

4-11  Comparison  of  Preliminary  Concept  and  Alternatives  for  Digital 

Production 4-69 

4-12  Comparative  Summary  of  Storage  Alternatives 4-71 

4-13  Mastering,  Replication  and  TM  Supply  Alternatives 4-77 

4-14  Navy  TMs  Converted  from  Pages  to  Digital  Bits 4-93 

4-15  NTIP  System  Management  Function 4-99 

4-16  NTIPS  Operations  Management  Function 4-101 


SECTION  S 

EXECUTIVE  SUMMARY 


Subsection  S.l  - NTIPS  Objectives 

5.1.1  The  Navy  TM  Problem  Involves  Technical,  Human  Factors, 

and  Procedural  Elements S-0 

5.1.2  The  Achievement  of  the  NTIP  Program  Goals  Requires 

a Definitive  Preliminary  Concept S-1 

Subsection  S.2  - System  Concept 

5.2.1  Overview  of  Preliminary  NTIP  System  Concept. S-2 

5.2. 2 TM  Acquisition  Must  Insure  that  Technical  Information 

is  Properly  Defined,  Specified,  and  Procured S-3 

5.2. 3 The  Approach  to  Content  Generation  Aims  to  Reduce 

Errors  and  Increase  Efficiency  in  the  TM  Writing  Process  ....  S-4 

5.2. 4 The  Key  Feature  of  the  Publishing  Subsystem  is  the 

Computerized  Production  Method S-5 

5.2. 5 Distribution  Control  is  Computerized  to  get  the  Right 

TM/Update  to  the  Right  User S-6 

5.2. 6 NTIPS  Management  Subsystem  Provides  Control  at  Both 

"Corporate"  and  "Division"  Levels  S-7 

Subsection  S.3  - System  Evaluation 

S.3.1  Plans  for  System  Evaluation  and  Cost  Analysis S-8 


Section  S - Executive  Summary 
Subsection  S.l  - NTIPS  Objectives 


The  Naw  TM  Problem  Involves  Technical, 


Human  Factors,  and  Procedural  Elements 


NTIPS 


• TM  Specifications  Not  Tailored  to  Unique  Equipment  Requirements 

• TM  Contents  and  Presentation  Techniques  not  Matched  to  the  User 

• Development  of  TMs  not  Coordinated  with  Training 

• Engineering/Manufacturing  Data  Base  Not  Suited  to  TM  Needs 

• TM  Writers  Guide  and  TM  Planning  Guides  Not  Available 

• TM  Publishing,  Updating,  Distribution,  and  Archives  are  Slow  and 
Archaic 

• TM  Process  Unresponsive  to  User  Feedback 


V y 

The  problem  faced  by  NTIPS  is  the  failure  of  Navy  technical  manuals  to  pro- 
vide fleet  personnel  with  accurate,  usable,  and  up-to-date  information.  Consequences 
of  this  failure  are  improper  equipment  operation,  inadequate  preventive  maintenance, 
and  increased  time  for  fault  isolation  and  repair.  The  key  problems  are  shown  above. 

First,  TM  specifications  do  not  provide  for  the  unique  nature  of  the  equip- 
ment being  procured.  Secondly,  the  TM  contents  and  presentation  techniques  are 
specified  in  a general  way  which  does  not  take  into  account  the  abilities,  experience, 
and  working  environment  of  the  user.  Also,  TMs  currently  being  produced  ohen 
do  not  meet  training  needs  because  of  the  lacl<  of  coordination  between  the  two 
fields. 

In  the  development  of  TMs,  two  major  problems  exist.  The  first  is  the  failure 
of  the  engineering  drawings,  reports,  and  data  to  provide  readily  usable  information 
for  the  development  of  technical  manuals.  This  data  is  currently  geared  toward 
specifying  the  hardware  for  fabrication  purposes.  It  does  not  provide  an  equal  mea- 
sure of  operator-  and  maintenance-oriented  data.  The  second  problem  concerns 
the  lack  of  practical  and  definitive  TM  writers  guides  and  TM  development  planning 
and  management  guides.  The  writers  guides  would  introduce  the  TM  writer  to  the 
NTIPS  system  and  provide  "how  to"  instructions  on  new  techniques  of  presentation 
and  readability.  The  planning  and  management  handbooks  would  assist  the  TM  engi- 
neers in  understanding  and  applying  techniques  for  effective  TM  development. 

The  failure  of  the  present  system  to  acknowledge  or  act  on  user-initiated 
corrections  and  today's  time-consuming  update  methods  make  the  user  reluctant 
to  use  existing  corrective  feedback  methods.  To  improve  efficiency,  increased  auto- 
mation of  publishing,  production,  distribution,  and  archival  functions  is  required. 
Solutions  are  needed  which  are  integrated,  Navy-wide,  cost  effective,  and  transi- 
tionable  from  the  "old"  TM  system. 
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Section  S - Executive  Summary 
Subsection  S.l  - NTIPS  Objectives 


Achievement  of  the  NTIP  Prt)gram 

Goals  Requires  a Definitive  Preliminary 

NTIPS 

Concept 

NTIP  Program  Goals 

• Reduce  Job  Performance  Time 
and  errors 

• Reduce  Training  Time 

• Reduce  TM  Life-Cycle  Costs 


Task  3 Objectives 

• Synthesize  System  Configuration 

• Develop  Preliminary  System  Concept  and 
Functional  and  Subsystem-Level  Alternatives 

• Identify  Additional  R&D  Requirements 
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Program  Plan 
• Phase  I — 

- Task  1 

- Task  2 

- Task  3 
— Task  4 

- Task  5 
— Task  6 

- Task  7 


Systems  and  Feasibility  Tradeoff  Analyses 

— Analysis  of  current/proposed  TM  systems 

— Initial  NTIPP  functional  requirements 

— Preliminary  NTIP  System  concept  and  alternative  configurations 

— Refinement  of  preliminary  NTIP  System  concept  and  perform- 
ance analysis 

— Cost  analysis 

— NTIP  System  functional  definitions 

— Planning  for  subsequent  phases  of  NTIPP 


• Phase  II  — Detailed  Design  and  Critical  Element  Testing 

• Phase  III  - Prototype  Testing  and  Development  of  Implementation  Recom- 

mendations 


V 


The  goal  of  the  current  phase  of  the  NTIP  Program  (Phase  I,  Systems  and 
Feasibility  Tradeoff  Analyses)  is  the  development  of  a functional  definition  of  the 
NTIP  System  that  will  provide  the  basis  for  the  detailed  design  effort  in  Phase  II. 
The  importance  of  Phase  I is  underscored  by  the  fact  that  the  quality  of  the  concept 
formulated  will  ultimately  determine  the  degree  of  attainment  of  the  NTIP  Program 
performance  goals.  These  goals  include:  reduction  in  user  job  performance  time 
by  10%  and  errors  by  50%,  reduction  in  training  time  by  5 to  25%,  and  reduction 
in  TM  life-cycle  costs  by  30%. 

The  objectives  of  Task  3 were  to  (a)  synthesize  a system  configuration, 

(b)  identify  functional  and  subsystem-level  alternatives,  and  (c)  identify  areas  where 
additional  research  and  development  are  required.  In  meeting  these  objectives, 
a preliminary  system  concept  was  developed  which  reflects  the  system-level  and 
functional  requirements  developed  in  Task  2 (and  refined  during  Teisk  3).  In  addi- 
tion, the  preliminary  concept  required  sufficient  detail  to  permit  the  conduct  of 
performance  eveiluations  (Task  4)  and  cost  evaluations  (Task  5).  Task  3 also  identi- 
fied alternative  approaches  to  implementing  the  requirements  that  were  deemed 
feasible  on  the  basis  of  a gross-level  analysis  with  respect  to  practicality,  cost, 
affordability,  and  performance. 

A research  approach  consisting  of  problem  identification,  performance  of 
detailed  studies  related  to  the  problems  identified,  and  postulation  of  candidate 
solutions  was  applied  to  each  subsystem  throughout  the  Task  1,  2,  and  3 efforts. 
Evaluation  of  candidate  solutions,  and  selection  of  a preliminary  concept  and  al- 
ternatives were  accomplished  exclusively  during  the  Task  3 effort. 
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^ The  preliminary  NTIP  System  concept  takes  full  advantage  of  existing  TM 

expertise  within  Navy  organizations  and  emphasizes  the  importance  of  developing 
TMs  that  match  the  information  needs  of  the  user.  This  approach  provides  the  NTIPS 
subsysteins  responsible  for  acquiring  TMs  with  the  ability  to  focus  resources  on  this 
key  area,  with  guidance  and  policy  supplied  by  NTIPS  management. 

The  Management  Subsystem  utilizes  a single  systems  management  function 
to  guide  the  NTIPS  system  as  a whole,  and  second-level  operations  management 
functions  which  are  dedicated  to  the  major  acquisition  activities  (procurers  of  systems/ 
equipments).  The  TM  Acquisition  Subsystems,  dedicated  to  each  major  acquisition  ac- 
tivity, specify  the  precise  TM  requirements  for  each  procurement  and  implement  pro- 
, curement  procedures  to  ensure  timeliness  and  quality  in  TMs. 

The  Content  Generation  Subsystem  is  critical  in  that  it  represents  the  most 
significant  and  final  point  of  impact  on  technical  information  quality.  In  this  ap- 
proach, the  Contractors  continue  to  be  responsible  for  collecting  the  data,  estimating 
the  proposed  TM  acquisition  cost,  preparing  TM  planning  documents,  writing  the 
TM,  critiquing  the  TM,  and  performing  validation,  but  under  new  ground  rules  and 
better  guidelines. 

Publishing  provides  decentralized  internal  Navy  capabilities  to  ace»  pt  the 
I equipment  contractor's  digital  output  for  processing  through  production,  n.  istering, 

j replication,  and  final  delivery.  A feature  of  this  concept  is  automated  facilities 

j to  process  new  and  updated  text  and  paphics. 

1 Distribution  controls  the  initial  distribution  of  new  and  updated  TMs,  the 

I storage  and  delivery  of  TMs  for  resupply,  and  TM  archival  storage.  It  features  elec- 

I tronic  media  for  working  archives  and  automation  of  distribution  control. 
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f TM  Acquisition  Must  Insure  that  Technical 
Information  is  Properly  Defined, 
Specified,  and  Procured 


• User-Data  Match  Model  - Provides  a means  by  which  user-optimized 
presentation  techniques,  related  to  his  personnel  characteristics,  tasks, 
and  working  environment,  are  identified 

• Modular  Concept  - Provides  the  means  to  custom-tailor  a TM  specifi- 
cation to  a particular  procurement  and  to  reduce  redundancy  and  extran- 
eous information  in  the  specification 

• Specification  Modules  — Contain  precise  requirements  for  the  technical 
content,  presentation  techniques,  readability,  vocabulary,  access,  publish- 
ing processes,  and  quality  control  of  TMs 

• Dedicated  TM  Procurement  Function  — Operates  under  NTIPS  organ- 
izational structure  to  provide  customized  TM  procurement  services  for 
a major  acquisition  activity 

• TM  Engineer  - Oversees  development  of  TM  requirements,  delivery, 
scheduling,  proposal  and  contract  preparation,  quality  assurance,  bud- 
geting and  funding,  and  contract  administration 

V ZZ / 

The  TM  Acquisition  Subsystem  consists  of  three  functions:  user-data  match, 
TM  specifications,  and  TM  procurement.  These  functions  are  responsible  for  de- 
termining user-data  requirements,  specifying  the  requirements,  and  purchasing  the 
data.  This  subsystem  is  critical  to  successful  system  operation  since  it  has  the  first 
and  most  significant  impact  on  determining  TM  design.  Other  subsystems  of  NTIPS 
are  not  equipped  to  mo^fy  subtle  mistakes  or  decisions  made  by  this  subsystem, 
and  errors  made  will  eventually  be  reflected  in  TMs  and  by  the  technician's  inability 
to  effectively  use  his  TMs. 

A user-data  match  model  is  proposed  for  aiding  the  selection  of  the  best 
choices  of  information  types  that  could  be  supplied  to  a user.  This  model  utilizes 
three  matrices  which  relate  user  personnel  characteristics,  presentation  components, 
equipment  type  and  task  analysis,  upon  which  the  selection  of  presentation  tech- 
f niques  are  based. 

Modular  TM  specifications  afford  the  advantage  of  stating  TM  requirements 
in  bite-sized  chunks,  or  modules.  These  modules  can  then  be  combined  in  a multi- 
tude of  ways  to  custom-tailor  TM  specifications  to  specific  TM  procurements.  Com- 
puter-aided processing,  storage,  selection,  formatting,  and  updating  of  the  specifica- 
tion modules  also  enhances  their  ease  of  use  and  the  capability  to  keep  the  specifica- 
tion modules  current  with  state-of-the-art  presentation  technologies. 
l Dedicated  TM  procurement  functions  within  NTIPS,  run  by  Navy  TM  engi- 

I neers  with  "captured"  funds  that  «ire  divorced  from  hardware  acquisition  activities, 

i afford  better  organizational  and  funding  control  of  this  function.  The  procurement 

1 of  TMs  and  budgeting  of  funds  by  a single,  responsible  expert  activity  should  elimi- 

t nate  the  problems  due  to  inconsistent  requirements  and  inappropriate  funding  prior- 

[ ities,  and  thus  improve  the  resulting  TM  product. 
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/^hc  Approach  to  Content  Generation 

Aims  to  Reduce  Errors  and  Increase 

NTIPS 

Efficiency  in  the  TM  Writing  Process 

• TM  Engineer 

- Plans,  initiates  and  supervises  TM  development  tasks 
and  establishes  interrelationships  with  design  engineer- 
ing, ILS,  and  QA  activities 

• TM  Development  Guide 

- Aids  TM  engineers  in  planning  and  managing  develop- 
ment tasks 

• Coordinated  Planning 

- Provides  compatibility  of  TM  and  other  ILS  element 
estimates  and  planning  documents  for  completely  inte- 
grated support  package 

• Upgraded  Writing  Staff 

- Provides  more  efficient  data  transformation 

• Combined  TM  Reviews  with  Validation 

— Ensures  TM  accuracy  and  completeness 

• Post-Program  Review 

- Provides  means  for  improving  TM  acquisition  system 

V J 

The  content  generation  subsystem  consists  of  three  functions  (estimating, 
planning  and  writing)  for  developing  new  and  updated  TMs.  Content  generation 
is  the  most  significant  part  of  NTIPS  because  it  is  the  final  point  of  impact  on  tech- 
nical information  quality.  Hence,  each  function  contains  features  that  are  designed 
to  reduce  errors  in  the  process  of  transforming  technical  data  contained  in  the  engi- 
neering/manufacturing data  base  into  technical  information. 

A new  position  is  created  that  calls  for  a TM  engineer,  who  would  be  respon- 
sible for  planning,  initiating  and  supervising  all  tasks  associated  with  content  gener- 
ation. His  responsibilities  include  coordinated  planning  and  review  of  estimating 
and  planning  documents  with  other  ILS  elements  to  provide  the  user  with  a complete 
and  compatible  integrated  logistic  support  package  (i.e.,  TMs,  training,  spares  provis- 
ioning, etc.). 

Detailed  guidance  in  the  form  of  a TM  Development  Guide,  which  supple- 
ments instructions  contained  in  TM  requirements,  would  be  produced.  This  guide 
would  provide  the  TM  engineer  step-by-step  instructions  on  how  and  when  to  accom- 
plish the  TM  development  tasks. 

The  procuring  activity's  final  review  would  be  combined  with  the  technical 
review  and  TM  validation.  This  would  provide  resolution  of  TM  problems  through 
a joint  effort  of  all  TM  program  participants  and  would  improve  TM  completeness, 
technical  accuracy,  and  user  effectiveness. 

The  engineering/manufacturing  data  base  would  be  improved  by  requiring 
the  addition  of  maintenance  data.  Also,  computer  processing  would  be  employed 
to  make  the  data  base  more  accurate  and  timely  for  the  content  generator. 
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The  Key  Feature  of  the  Publishing  Subsystem 


is  the  Computerized  Production  Method 


NTIPS 


• Produces  TMs  in  Paper  and  Microform  Media 


A 


O' 


• Fully  Automated,  Internal  Navy  Capability  for  Text  and  Graphic  Production 

- Will  accept  contractor’s  technical  information  in  digital  form 

— Will  accept  Navy  technical  information  in  paper,  and  convert  by  OCR 


• Standardized  Digital  Publishing  Methods  and  Requirements  Among  the  Various 
Contractors  and  Navy  Publications  Operations 


V y 

The  preliminary  concept  of  the  Publishing  Subsystem  provides  for  Navy 
capability  to  not  only  process  their  own  technical  information  into  TMs,  but  to 
process  equipment  contractor's  technical  information  into  TMs  as  well. 

The  capability  provided  must  handle  over  three  million  pages  each  year, 
the  majority  of  which  are  presently  processed  (at  least  through  mastering)  by  equip- 
ment contractors'  publishing  activities.  Presently,  the  Navy  creates  and  processes 
less  than  50  thousand  pages  each  year  and  converts  only  about  100  thousand  pages 
yearly  to  a TM  digital  data  base  with  their  TRUMP  system. 

To  handle  the  projected  three  million  plus  pages  per  year,  a digital  (com- 
puterized) TM  data  base  must  be  created  and  maintained  current  for  all  in-produc- 
tion equipment.  Although  the  digital  data  base  is  essential  for  updating  TMs  after 
the  equipment  transitions  from  in-production  to  out-of-production  status,  the  digital 
data  base  is  also  necessary  to  digitally  produce  the  in-production  equipment  tech- 
nical information  as  TMs  for  replication  and  delivery  to  the  users. 

Fully  automated  text  and  graphic  processing  is  the  key  feature  that  enables 
the  digital  production  needed  in  this  subsystem.  E’ublishing  must  also  provide  a capa- 
bility to  output  the  digital  production  as  masters  of  TM  pages  and  for  their  replica- 
tion and  delivery. 

Another  key  feature  is  to  standardize  digital  publishing  methods  to  facilitate 
the  Navy  processing  of  the  various  equipment  contractors'  technical  information  | 

and  the  exchanging  of  work  among  Navy  publishing  operations.  Having  the  same  i 

functional  capability  at  each  Navy  publishing  facility  will  help  provide  needed  i 

compatibility.  j 
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• Decentralized  Initial  Distribution  Control  Capability 

Automated  Hardware/TM  Configuration  Management  via  MIS 
Complete  Use/Address  File  via  MIS 

• Centralized  TM  Resupply  Capability  within  NTIPS 

Automated  Materials  Management  via  MIS 

Physical  Storage  to  Accommodate  Printed  Paper  Books  and  Microforms 

• Centralized  Dual  Archives  Support  Publishing  Activities 

Digital  Working  Archive  to  Contain  the  Digital  TM  Data  Base 

Protected,  Controlled  Historical  Archive  to  Contain  Master  Copy  of  All 
Navy  TMs 


^distribution  Control  is  Computerized 
to  get  the  Right  TM/Update 
to  the  Right  User 


V J 

The  Distribution  Subsystem  must  provide  the  capability  to  control  the  TM 
distribution  for  12,000  new  procurement  actions  and  20,000  TM  updates  each  year. 
This  role  of  initial  distribution  control  works  closely  with  TM  procurement  in  the 
TM  Acquisition  Subsystem.  A key  element  of  distribution  control  is  the  mechanism 
to  assure  that  the  configuration  of  the  TM  furnished  to  the  user  matches  the  hard- 
ware configuration  being  used.  Additionally,  this  function  assures  the  timely  deliv- 
ery to  users  of  their  TMs  and  all  subsequent  updates.  Both  TM/equipment  config- 
uration management  and  the  user/address  file  are  elements  of  the  Management 
Information  System  (MIS). 

The  second  capability  needed  is  to  provide  a warehouse  for  paper  and/or 
microform  copies  of  150,000  different  TMs.  This  function,  TM  resupply,  maintains 
an  adequate  supply  of  each  active  TM  to  respond  to  user  requests  for  TMs  and  coor- 
dinates replenishment  with  the  major  procurement  activities  when  stock  levels 
decline. 

Finally,  the  Distribution  Subsystem  provides  a dual  archive  of  TM  masters. 

A working  archive  provides  a digital  data  base  of  all  active  TMs  for  processing  by 
the  Publishing  Subsystem.  The  working  archive  is  used  for  updating  TMs  when  equip- 
ment is  modified.  The  other,  historical  archive,  is  the  repository  of  master  copies 
of  all  TMs  used  by  the  Navy.  Although  designated  "historical,"  this  archive  provides 
a back-up  for  the  working  archive. 
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The  NTIPS  Management  subsystem  is  a two-tiered  design  that  establishes 
system  policies  and  objectives  at  a centralized  system  management  level,  and  pro- 
vides operational  management  support  to  the  acquisition  activities  at  the  operations 
management  level.  At  the  first  level,  the  NTIP  System  Management  Subfunction  is 
reponsible  for  the  overall  management  of  NTIPS,  and  establishes  and  promulgates 
all  policies  necessary  for  system  operation.  The  system/product  improvement  engi- 
neering subfunction  establishes  quality  assurance  policy,  evaluates  TM  quality,  and 
assists  with  budget  reviews  and  long-range  planning.  The  research  and  development 
(RdcD)  subfunction  provides  Navy-wide  coordination  of  all  NTIPS-related  R<3cD  ef- 
forts and  monitors  on-going  DoD/lndustry  efforts  to  determine  applicability  to 
NTIPS.  Finally,  the  cost  analysis/forecasting  subfunction  performs  in-depth  anal- 
yses of  budgeting/scheduling  data  from  Navy-wide  NTIPS  activities. 

The  second-level  NTIPS  operations  management  function  is  dedicated  to 
the  TM  requirements  of  each  of  the  major  acquisition  activities.  The  NTIPS  oper- 
ations management  subfunction  is  responsible  for  guiding  the  operations  of  the 
NTIPS  activities  within  its  purview.  The  practices/procedures  subfunction  prepares 
detailed  operating  procedures  for  the  NTIPS  activities,  while  the  Management  In- 
formation System  (MIS)  maintains  the  management  data  collecting  and  reporting 
network  that  supports  the  NTIPS  operations.  The  remaining  three  subfunctions 
(configuration  accounting,  feedback/update,  cost  monitor/evaluation)  provide  the 
TM  configuration  index,  the  feedback  network,  the  out-of-production  TM  update 
system,  and  the  cost  monitoring  and  evaluation  system. 
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The  next  tasks  in  NTIPP  Phase  I are  refinement  of  the  system  concept  and 
evaluation  of  system  performance  (Task  4),  and  cost  analysis  (Task  5).  The  main 
steps  in  these  tasks  are  outlined  above. 

Task  3 described  about  25  functional  alternatives  to  the  preliminary  con- 
cept. The  first  step  of  the  evaluation  process  will  be  tradeoffs  among  all  alterna- 
tives defined  at  the  function  level.  The  next  step  will  be  the  development  of  three 
cost/risk-level  alternative  system  concepts  from  the  available  list  of  functional 
alternatives.  In  synthesizing  these  alternative  systems  from  a cost/risk  viewpoint, 
the  intent  is  not  to  select  the  ultimate  NTIP  System  strictly  from  these  three  al- 
ternatives, but  to  provide  a viable  context  in  which  to  conduct  the  system  perform- 
ance and  cost  evaluations. 

The  performance  analysis  will  employ  detailed  effectiveness  criteria  at 
the  functional  level,  including  both  features  of  effectiveness  (FOEs)  and  measures 
of  effectiveness  (MOEs).  In  this  analysis,  significant  gaps  in  the  data  base  may  be 
identified.  If  so,  opportunities  for  capture  of  the  data  during  Phase  II  will  be  identi- 
fied to  enable  confirmation  of  the  Phase  I tradeoffs. 

The  next  effort  will  be  to  develop  cost  comparisons  for  the  three  cost/risk 
system  concepts.  The  cost  analysis  will  treat  the  system  alternatives  on  a function- 
by-function  basis,  and  provide  cost  summaries  at  both  the  subsystem  and  system 
level.  Needed  cost  data,  not  currently  available,  will  be  identified. 

Finally,  matrices  will  be  developed  to  permit  comparison  of  performance 
and  cost  of  the  three  alternative  NTIP  systems  at  the  function  level.  These  matrices 
and  their  supporting  rationale  will  provide  the  information  relevant  to  the  decisions 
involved  in  selecting  the  NTIP  System  concept. 
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Section  1 - Introduction  and  Methodology 


1.1  OBJECTIVES  OF  TASK  3 


The  objective  of  Task  3 is  to  develop  a preliminary  system  concept  and  functional  and 
subsystem-level  alternatives  in  sufficient  depth  to  enable  performance  and  cost  evalua- 
tions, prior  to  the  functional  definition  of  the  selected  system  configuration. 

The  end  product  of  the  current  phase  of  the  NTIP  Program  (Phase  I,  Systems 
and  Feasibility  Tradeoff  Analyses)  is  the  development  of  functional  definitions 
of  the  NTIP  System  that  will  become  the  groundwork  for  the  detailed  design  effort 
in  Phase  11.  The  importance  of  Task  3 is  underlined  by  the  fact  that  the  quality 
of  the  concept  formulated  will  ultimately  determine  the  degree  of  attainment  of 
the  NTIP  Program  performance  goals.  These  goals  include  a reduction  in  user  job 
performance  time  (10%)  and  errors  (50%)  as  well  as  a reduction  in  training  time 
(5%  to  25%)  and  TM  life-cycle  costs  (30%). 

Phase  I of  the  NTIP  Program  consists  of  seven  tasks,  as  shown  in  Figure  1-1. 
Task  1 was  a survey  and  analysis  of  current  and  proposed  technical  manual  systems. 
Principal  emphasis  was  directed  to  U.S.  Navy  technical  manual  operations  (NAVAIR, 
NAVSEA,  NAVELEX),  but  for  comparison,  some  non-Navy  TM  activities  (Army, 

Air  Force)  were  also  examined.  The  resulting  information  base  is  contained  in  the 
NTIP  Task  1 Report,  which  is  supplemented  by  the  special  report,  "NTIPP  Fleet 
Survey  of  Technical  Manual  Users."  This  survey  was  conducted  at  Pacific  Fleet 
Activities  from  1 November  to  22  December  1976  by  an  NTIPS  survey  team  that 
interviewed  more  than  400  Navy  personnel.  User  comments  on  TMs  were 
documented  through  a direct  structured  interview  technique  using  a standard 
questionnaire. 

The  next  step  in  the  process  was  Task  2,  the  development  of  NTIPS  require- 
ments. These  requirements  serve  as  criteria  for  both  system  configuration  syn- 
thesis and  testing  the  acceptability  of  the  preliminary  concept  and  alternatives 
developed  during  Task  3.  Requirements  statements  were  arrived  at  principally 
through  analysis  of  information  researched  during  the  conduct  of  Task  1 and  the 
Fleet  Survey. 

The  objective  of  the  Task  3 effort  was  to  develop  a preliminary  NTIP  System 
concept  that  meets  the  system-level  and  functional  requirements  developed  in  Task  2 
(and  refined  as  a part  of  Task  3),  and  to  identify  functional  and  subsystem-level  al- 
ternatives. The  primary  work  of  this  task  was  to  identify  alternative  approaches  to 
implementing  the  requirements  that  were  deemed  feasible  on  the  basis  of  a gross 
level  analysis  with  respect  to  practicability,  cost,  affordability,  and  performance. 
However,  a detailed  discussion  of  the  advantages  and  disadvantages  of  each  alterna- 
tive was  intentionally  omitted  from  this  report  pending  the  results  of  the  perform- 
ance and  cost  evaluations  to  be  performed  in  Task  4 and  Task  5. 

As  an  example  of  this  process,  the  requirements  of  the  archive  may  be  met 
by  employing  computer  access  and  control  and  total  digital  storage  of  TMs.  This 
approach  may  meet  all  the  feasibility,  performance,  and  operating  cost  criteria, 
yet  fall  beyond  the  limits  of  affordability  criteria.  An  alternate  approach  would 
be  to  store  all  TMs  in  microform  using  computers  for  archival  access  and  control. 

An  additional  objective  was  to  identify  areas  where  additional  research 
and  development  are  required.  As  an  example,  user-data  matching  and  the  relation- 
ship between  TMs  and  Training  were  identified  as  needing  further  research  and  de- 
velopment during  Phase  II  of  the  NTIP  Program. 

The  preliminary  NTIP  System  concept  and  functional  alternatives  will  be 
evaluated  and  ranked  from  a performance  (Task  4)  and  a cost  (Task  5)  viewpoint. 
Based  upon  these  analyses,  selected  NTIP  System  concepts  will  be  functionally  de- 
fined in  Task  6.  The  functional  definitions  will  be  the  basis  for  detailed  design  and 
testing  in  Phase  II  of  the  NTIP  Program. 
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Figure  1-1.  Relationship  of  Task  3 to  Overall  NTIPP  Effort.  The  principal  objective  of  the  Task  3 
effort  was  to  synthesize  a preliminary  NTIP  System  concept  that  meets  the  requirements  developed 
in  Task  2 and  refined  in  Task  3,  define  functional  relationships,  and  identify  feasible  functional 
alternatives. 
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1.2  APPROACH  TO  TASK  3;  PRELIMINARY  N TIP  SYSTEM  CONCEPT  AND 
ALTERNATIVES 

The  approach  to  Task  3 involved  a refinement  of  the  Task  2 requirements  and  synthesis 
of  an  NTIP  System  configuration,  upon  which  the  preliminary  NTIP  System  concept 
and  functional  alternatives  were  then  structured.  

The  initial  step  in  Task  3 was  to  refine  the  initial  NTIPP  functional  require- 
ments at  both  the  system  and  functional  levels  based  on  research  conducted  to  date. 

Additionally,  the  requirements  were  analyzed  to  insure  that  they  respond  to  the 
NTIP  Program  goals  to  improve  fleet  and  training  readiness. 

An  NTIP  System  configuration  was  then  synthesized  from  a logical  analysis 
of  the  functions  required  and  their  allocation  to  a subsystem  organization.  Five 
subsystems  resulted:  TM  Acquisition,  Content  Generation,  Publishing,  Distribution, 
and  Management.  This  range  of  subsystems  involves  a variety  of  human  actions,  | 

mechanical  operations,  and  management  processes.  Hence,  a wide  variety  of  prob- 
lems is  resident  in  the  development  of  the  preliminary  NTIP  System  concept. 

This  requires  a broad  range  of  technical  approaches  - from  the  human  factors  as- 
pects of  presentation  techniques,  to  digital  production  of  TMs,  to  the  development 
of  a management  reporting  system. 

To  insure  that  the  proposed  NTIP  System  configuration  meets  its  operational 
requirements,  a set  of  Operational  Sequence  Diagrams  (OSD)  was  developed.  These 
OSDs  illustrate  the  sequence  of  events  which  must  occur  from  the  initiation  of  a 
TM  procurement  through  the  distribution  of  the  resulting  TM  to  the  user.  Also  in- 
cluded in  the  OSDs  are  on-going  activities  such  as  processing  of  feedback  reports, 
system  monitoring,  and  TM  resupply,  j 

A detailed  process  consisting  of  problem  indentification,  performance  of  j 

detailed  studies  related  to  identified  problems,  and  postulation  and  evaluation  of  ^ 

candidate  solutions  occurred  continually  throughout  the  Task  1 and  2 efforts.  | 

The  evaluation  of  candidate  solutions  and  selection  of  a preliminary  concept  and  | 

alternatives  was  performed  exclusively  during  the  Task  3 effort.  The  following  j 

paragraphs  present  examples  of  the  detailed  studies  performed  for  each  subsystem.  i 

Methods  of  User-Data  Matching  - A methodology  was  developed  for  match- 
ing- TM  presentation  techniques  to  the  user  based  upon  personnel  characteristics,  job 
tasks,  system/equipment  type,  and  environment.  The  human  factors  firm  of  Anacapa 
Sciences,  Santa  Barbara,  California,  was  employed  to  study  the  user-data  matching 
problem  and  to  develop  a method  for  selecting  presentations  suited  to  a particular 

user's  needs.  ^ 

New  Specification  System  - Detailed  analyses  of  existing  TM  specifications 
were  performed.  These  analyses  were  designed  to  determine  the  optimum  methods 
for  specifying  technical  content,  presentation  techniques,  readability,  access,  vocabulary,  ^ 

and  publication  processes  requirements.  . 

Content  of  Engineering/Manufacturing  Data  Base  - The  content  ol  the 
engineering/manufacturing  data  base  was  exatnined  to  determine  its  applicability 
to  the  development  of  technical  information.  This  examination  focused  on  the  po- 
tential for  requiring  the  inclusion  of  specific  types  of  maintenance  information  in  i 

the  data  base  which  would  facilitate  the  development  of  technical  information. 

Performing  a TM  Design  - The  problems  related  to  development  oj^  TM  de- 
sign disclosure  documents  such  as  bookplans  and  outlines  were  analyzed.  This  anal- 
ysis focused  on  the  role  of  human  factors  considerations,  the  required  level  of  detail, 
the  qualifications  and  types  of  personnel  involved,  and  the  need  for  coordination 
with  training  and  design  engineering. 

TM  Review  Team  Definition  - Criteria  for  standardizing  TM  review  teams 
were  established.  The  number  and  type  of  team  members  (to  include  user,  training, 
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and  design  eng  necring  participation)  and  the  responsibilities  of  each  participant 
were  determined. 

Defining  the  Role  of  Quality  Assurance  - The  amount  of  quality  assurance 
emphasis  that  should  be  applied  during  the  various  phases  of  TM  development  was 
determined.  Additionally,  the  extent  of  involvement  and  the  responsibility  of  both 
content  generating  and  T^l  acquisition  personnel  were  evaluated.  A major  portion 
of  this  study  was  performed  by  Hageman  Consulting  Services  of  Fort  Worth,  Texas. 

Upgrading  of  Technical  Writers  - Various  ways  of  upgrading  the  capabilities 
of  technied  writers  were  surveyed.  S~humber  of  potentially  feasible  approaches 
to  this  problem  were  uncovered,  such  as:  (1)  requiring  certification  of  TM  writers, 
(2)  requiring  that  TM  writers  be  graduate  engineers,  and  (3)  mandatory  contractor- 
conducted  TM  writer  training  courses. 

Plans  for  Applying  Known  Readability  Remedies  to  TMs  - A practical  plan 
was  prepared  to  apply  known  and  proven  methods  of  achieving  readable  writing  in 
TMs.  Existing  readability  measurement  formulas  were  analyzed  for  applicability 
to  technical  manuals  and  the  content  of  writers  guidelines  was  planned  to  include 
items  sucli  as  vocabulary  controls  and  readability,  writing,  and  editing  practices. 

Extent  of  Automated  Graphic  Processing  - Available  automated  graphic 
processing  systems  were  identified  and  their  capabilities  evaluated.  A macro  level 
analysis  was  conducted  to  determine  the  ability  of  automated  graphic  processing 
systems  to  meet  NTIPS  requirements  for  capacity  and  throughput  rate. 

ADP  Applications  to  the  Archive  - The  functions  of  the  archive  to  which 
A DP  canlje  applied  were  identified.  Techniques  of  indexing,  information  retrieval, 
cataloging,  and  storage  were  surveyed  to  determine  their  applicability  to  the  NTIPS 
archive. 

Methods  of  Monitoring  NTIP  System  Operating  Costs  - The  cost  monitoring 
points  and  methods  of  cost  collection  required  to  audit  NTIP  System  operating  costs 
were  identified.  Considerations  in  this  study  were  the  level  of  detail,  frequency, 
and  types  of  output  reports. 
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Section  2 - NTIPS  Requirements 


2,1  PROGRAM  GOALS  AND  SYSTEM-LEVEL  REQUIREMENTS 


The  Preliminary  NTIP  System  concept  is  initially  driven  by  a combination  of  program 
goals,  system-level  requirements,  and  system  constraints. 

The  Navy  Techical  Manual  System  (NT.viS)  Program  Development  Plansl.2 
cited  numerous  problems  and  deficiencies  in  the  current  Navy  system  of  TM  devel- 
opment, (N'livlS  is  now  the  Navy  Teclinical  Information  Presentation  System.) 
Recognition  of  these  problems  and  deficiencies  resulted  in  the  formulation  of  pro- 
gram goals  to  improve  fleet  and  training  readiness3.  These  goals  and  their  impact 
on  system  requirements  are  defined  in  Table  2-1.  these  goals,  combined  with  the 
NTIPS  analysis  of  current  and  proposed  TM  systems  (Task  1)  led  to  the  identification 
of  further  system-level  requirements  and  constraints  to  which  the  preliminary  NTIP 
System  concept  must  be  responsive,  as  discussed  below. 

Ease  of  N riPS  Implementation  - The  NTIP  System  must  evolve  from  the 
current  Navy  TM  system.  Consideration  must  be  given  to  minimizing  the  impact 
on  existing  Navy  organizations,  personnel,  and  facilities.  For  example,  the  NTIPS 
mangement  and  TM  acquisition  organizations  must  be  integrated  into  the  existing 
Navy  structures  for  performing  these  functions,  rather  than  displace  them. 

Compatibility  with  the  System  Acquisition  Process  - System  Acquisition 
Process  refers  to  the  process  by  which  military  hardware  (e.g.,  ship,  aircraft,  or 
individual  piece  of  electrical,  electronic,  or  mechanical  equipment)  is  procured. 

This  process  is  carried  out  through  four  phases;  concept  formulation,  validation, 
full-scale  development,  and  production/deployment/support. 

The  NTIP  System  must  respond  to  requirements  placed  on  it  by  the  System 
Acquisition  Process  through  Integrated  Logistic  Support  activities  in  order  to  ensure 
the  development  of  quality  TMs.  The  following  are  the  requirements  to  which  NTIPS 
must  respond  during  the  various  System  Acquisition  Process  phases. 


Concept  Formulation: 


• Define  preliminary  requirements  for  TMs  with  respect  to  the  operational 
and  support  capability  of  the  proposed  system. 

• Formulate  candidate  TM  concepts  matched  to  the  user  needs. 

• Select  viable  TM  concepts  for  consideration  during  concept  validation 
phase. 

• Develop  preliminary  planning  to  implement  TM  concepts. 

Validation: 


Define  formal  TM  requirements  which  are  compatible  with  the  proposed 
system  support  concept. 

Establish  criteria  for  assessing  compliance  with  formal  TM  requirements. 
Evaluate  proposed  TM  approaches  for  adherence  to  formal  TM  require- 
ments based  on  established  criteria. 


1.  Fuller,  J.J.,  and  Sulit,  R.A.,  Navy  Technical  Manual  System  (NTMS)  Implementa- 
tion of  Program  Development  Plan  During  FY  75,  DTNSRDC,  January  1975. 

2.  Sulit,  R.A.,  et  al.  Navy  Technical  Manual  System  (NTMS)  Program  Development 
Plan,  DTNSRDC,  November  1974. 

3.  Fuller,  J.J.,  and  Sulit,  R.A,,  Navy  Technical  Manual  System  (NTMS)  Program 
Summary,  DTNSRDC,  March  1976. 
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TABLE  2-1,  IMPACT  OF  NTIP  PROGRAM  GOALS 
ON  SYSTEM  REQUIREMENTS 


Program  Goals 

Impact  on  System  Requirements 

• Improve  TM  compre- 
hensibility and  usability 
so  as  to  reduce 

- Job  performance 
time  by  10% 

- Job  performance 
errors  by  30% 

1 

1 

Provide  a user-data  match  function  that  will  maximize 
user  effectiveness  by  selecting  presentation  techniques 
for  individual  procurements  based  upon: 

- Personnel  characteristics 

- Equipment/system  type 

- Environmental  constraints 

- Task  analysis 

Provide  a TM  specifieation  function  that  will  develop 
guidelines  for: 

- Readability 

1 - Vocabulary 

- Presentation  techniques 

- Technical  content 

- Access 

Maximize  the  utility  of  data  relative  to  TM  effective- 
ness currently  in  the  Maintenance  Material  Management 
(3-M)  reports,  as  well  as  enhance  the  utility  through 
improved  recording  of  specifics  concerning  TMs. 

• Insure  that  TM  delivery 
precedes  hardware  de- 
livery by  at  least 

2 months 

Improve  the  form  and  content  of  the  engineering/ 

1 manufactuirng  data  base  so  that  it  can  be  more  effi- 
ciently converted  to  technical  information. 

• Reduce  training  time  I 

by  5 to  25% 

1 

Provide  guidelines  for  the  performance  of  a Training/ 
Technical  Manual  Tradeoff  for  individual 
procurements. 

Provide  for  content  generator  coordination  with  train- 
ing during  TM  development  cycle. 

• Reduce  TM  life-cycle  ; 
costs  by  30% 

1 

Improve  the  form  and  content  of  the  engineering/ 
manufacturing  data  base  so  that  it  can  be  more  effi- 
ciently converted  to  technical  information. 

Provide  a mechanism  for  improving  content  generation 
planning  and  writing  efforts. 

• Reduce  update  cycle 
time  by  25% 

Provide  a centrally  controlled  multimedia  storage  fa- 
cility for  both  active  and  inactive  TM  data  banks. 

• Standardize  and  improve 
coordination  of  the  TM 
acquisition  process 

Provide  a centralized  system  management  organization 
which  establishes  TM  acquisition  policy  for  the  entire 
Navy, 

• Provide  data  for  project 
management  life-cycle 
cost  decisions 

Provide  a mechanism  for  monitoring  and  evaluating 
all  TM-related  costs. 

W 
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2.1  PROGRA.'vl  GOALS  AND  SYSTEM-LEVEL  REQUIREMENTS 
(Continued) 

Eull-Seale  Development: 

• Provide  guidance  to  selected  content  generator  (i.e.,  in  most  cases  the 
(Contractor  developing  tlie  system/equipment)  and  insure  compliance 
with  TM  concept  and  schedules. 

• Review  preliminary  TM  and  verify  compliance  with  requirement.-.. 

Product  ion/ Deploy  men  t/Support: 

• Develop  plans  and  schedules  for  production  of  final  1 Al 

• Review  final  T.Vl  and  verify  compliance  with  requirements 

• Publish  and  distribute  final  TM 

• Maintain  TMs 

training  - Technical  manuals  are  often  the  primary  source  of  printed  mate- 
rial used  during  training.  However,  there  are  certain  characteristics  of  T \ls  that 
make  them  less  than  adequate  for  training  applications  (e.g.,  not  structured  iti  lesson 
plan  form,  lack  of  utilization  of  learning  principles,  etc.). 

The  NTIP  System  must  provide  for  the  involvement  of  th<  training  commun- 
ity in  the  development  of  technical  manuals.  I'his  involvement  must  insure  TMs 
that  not  only  provide  adequate  on-the-job  information,  but  are  compatible  with 
the  requirements  for  the  training  of  those  individuals  who  will  eventually  have  to 
use  the  manuals.  Additionally,  guidelines  must  be  developed  for  use  in  performing 
1 raining/Technical  Manual  Tradeoffs  for  individual  procurements. 

Exploiting  Automation  Technology  - Automation  would  have  the  most  pro- 
nounced  effects  on  the  publishing  and  management  areas  of  the  NTIP  System,  but 
might  also  have  significant  implications  for  distribution.  In  order  to  efficiently 
publish  the  large  quantity  of  technical  information  received  in  various  media  from 
content  generators,  the  N TIP  System  requires  state-of-the-art  automated  text  and 
graphic  processing  equipment.  Additionally,  a fully  automated  Management  Infor- 
mation System  (MIS)  is  required  to  store  and  analyze  NTTP  System  cost  and  perfor- 
mance data,  as  well  as  to  control  TM  initial  distribution  and  resupply. 

System  Capacity  - The  term  "capacity"  refers  to  two  parameters:  volume 
a id  speed.  Vvith  regard  to  volume.  Table  2-2  presents  a summary  of  the  current 
level  of  Navy  technical  manual  activity.  It  is  projected  that  this  level  of  activity 
will  remain  fairly  constant  over  the  next  several  years,  fluctuating  at  an  approxi- 
mate rate  of  plus/minus  2 to  3 percent  per  year.  These  fluctuations  are  attributable 
to  increases  in  volume  as  new  material  is  processed,  and  decreases  in  volume  as 
old  (i.e.,  obsolete)  material  is  deleted  from  the  system.  These  figures  provide  a 
fairly  sound  estimate  of  the  volume  requirement  that  will  be  placed  upon  the  NTIP 
System.  Volume  not  only  impacts  the  system  from  a production  standpoint,  but  also 
has  staffing  implications  because  of  the  number  of  programs  to  be  managed. 

Speed  refers  to  how  fast  the  system  produces  and  delivers  TMs.  The  basic 
requirement  is  that  NTIPS  must  always  be  capable  of  deliverying  new  TMs  concur- 
rent with  system/equipment  delivery.  The  period  of  time  for  producing  TMs  will 
vary  depending  upon  whether  a war  or  peace  situation  exists. 

In  considering  delivery  of  T '.vl  updates,  an  additional  requirement  exists  for 
the  speed  parameter.  Updates  are  categorized  into  one  of  three  priority  classifica- 
tions: (1)  emergency,  (2)  urgent,  and  (3)  routine.  An  emergency  priority  involves 
action  to  alleviate  a condition  that  could  cause  injury  to  personnel,  extensive  dam- 
age to  equipment  or  property,  or  inability  to  maintain  equipment  in  an  operational 
condition.  An  emergency  priority  requires  a response  within  three  calendar  days. 

An  urgent  priority  involves  action  to  alleviate  a condition  that  could  result  in  dam- 
age to  equipment  or  property,  a reduction  in  equipment  operational  efficiency,  or 
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corrective  action  within  10  working  days.  A routine  priority  involves  normal  manual 
improvement,  potential  personnel/equipment  hazards  with  prolonged  use,  or  a re- 
duced operational  equipment  life.  A routine  priority  requires  that  corrective  action 
be  initiated  within  60  working  days. 

Developing  More  Effective  TM  Presentation  Techniques  - A primary  objec- 
tive of  the  NflP  System  is  the  development  of  TM  presentation  techniques  (FOMM, 
JPA,  etc.)  that  satisfy  the  information  needs  of  the  user.  There  must  be  adequate 
provisions  in  the  system  for  assessing  the  real  everyday  user  requirements  for 
technical  information,  responding  to  these  requirements  in  the  TM  design,  and  eval- 
uating the  on-the-job  effectiveness  of  the  TM.  The  system  must  more  effectively 
match  existing  presentation  techniques  to  the  user,  as  well  as  develop  new  techniques 
when  called  for  by  changing  user  requirements  or  the  failure  of  existing  techniques 
to  be  effective. 


TABLE  2-2.  CURRENT  VOLUME  OF  NAVY  TECHNICAL  MANUALS 


NAVSEA 

NAVAIR 

NAVELEX 

Total  Navy 

Inventory 

Number  of  TMs 

Number  of  Text  Pages 

Number  of  Art  Pages 

Ave.  Total  Pgs/PUs  per  TM 

Ave . Number  Text  Pgs.perTM 
Ave. Number  Art  Pgs/PUs  per  TM 
Total  TM  Pages 

95,000 

13.700.000 
5,600,000 

203/265 

121 

82/144 

19.300.000 

25,000 

1.500.000 
1,000,000 

100/-- 

60 

40/-- 

2.500.000 

20,000 

2,200,000 

900,000 

115/190 

no 

45/80 

3,100,000 

140,000 

17.400.000 
7,500,000 

188/ — 
105 

56/-- 

24.900.000 

Yearly  Production  - New/Reissue 
Number  of  TMs 

Number  of  Text  Pages 

Number  of  Art  Pages 

Total  TM  Pages 

10,000 

2,000,000 

850,000 

2,850,000 

750+350  (F) 
220,000 
55,000 
275,000 

500 

55,000 

22.500 

77.500 

11,600 

2,275,000 

927,500 

3,202,500 

Yearly  Production  - Update 

Number  of  TMs 

Number  of  Text  Pages 

Number  of  Art  Pages 

Total  TM  Pages 

144-240,000 

96-160,000 

240-400,000 

3,400-4,000 

255.000 
85,000 

340.000 

36-53,000 

14-22,000 

50-75,000 

435-548,000 

195-267,000 

630-815,000 

Out -of  Production  TMs 

Backlog  Pages 

Pages  Added  Yearly 

51,000 

5,250-16,000 

15,000 
1,000  j 

1 

105,000 

6,000 

171,000 

12,250-23,000 

% of  Work  Subcontracted 

85% 

] 

New  98% 

Update  90% 

98% 

— 

(F)  TMs  covering  U.S.  Aircraft  purchased  by  foreign  governments. 

Sources  are:  NAVSEA  data  - Stanford  Research  Institute  Report,  "Requirements  and  Alterna- 
tive Designs  for  Automating  the  Publication  of  NAVSEA  MOTD 
at  the  NSDSA,"  January  1977. 

NAVAIR  data  - Representative  of  NATSF  - 1977 
NAVELEX  data  - Representative  of  NAVELEX  - 1977 
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Section  2 - NTIPS  Requirements 


2.1  PROGRAM  goals  AND  SYSTEM-LEVEL  REQUIREMENTS  (Continued) 


Media  Flexibility  - It  can  be  expected  that  at  the  time  of  NTIP  System  im- 
plementation, technical  information  will  be  presented  to  the  user  in  the  same  media 
as  are  currently  used  - printed  paper  books  and  cartridge  and  fiche  microforms. 

This  imposes  a basic  requirement  on  the  NTIP  System  to  be  capable  of  producing 
technical  information  in  these  three  media.  However,  advances  in  technology  may 
provide  new  alternatives  in  the  area  of  presentation  media  such  as  video  discs  and 
digital  holograms.  This  imposes  an  additional  requirement  on  the  NTIP  System  to 
be  capable  of  producing  technical  information  in  any  of  these  advanced  media. 

Use  of  Contracting  - The  Office  of  Management  and  Budget  Circular  0MB- 
A76  states  that  it  shall  be  the  ".  . . policy  of  Government  to  rely  on  the  private 
sector  for  its  goods  and  services  except  where  such  action  is  not  in  the  national 
interest."  The  NTIP  System  must  comply  with  tliis  policy  while  maintaining  some 
level  of  internal  capability.  Questions  that  bear  on  the  contracting  aspect  of  the 
NTIP  System  are,  for  example,  should  the  system  adopt  the  policy  of  contracting 
out  some  fixed  percentage  of  the  workload?  U'hat  level  of  internal  capability 
must  be  maintained  in  order  to  ensure  a response  capability  during  emergency 
situations  (e.g.,  war)?  How  should  the  system  be  designed  in  terms  of  its  capability 
to  accommodate  fluctuations  against  a day-to-day  workload? 

Responding  to  User  Feedback  - A primary  objective  of  the  iNTIP  System 
is  to  establish  a feedback  process  that  permits  continual  monitoring,  evaluation, 
and  response  to  user-initiated  comments  and  suggestions  concerning  TMs  in  the 
field.  Phis  process  must,  in  addition,  be  viable  for  several  classes  of  user:  mainte- 
nance technicians,  system/equipment  operators,  and  the  training  community. 

Usability  ol  Engineering/Manufacturing  Data  Base  - The  engineering/ 
manufacturing  data  base  (engineering  drawings,  test  specifications,  wire  lists,  parts 
lists,  etc.)  is  the  major  source  of  data  used  to  develop  technical  information.  The 
development  of  technical  information  is  thus  highly  dependent  upon  the  content, 
quality,  format,  and  completeness  of  the  data,  as  well  as  the  facility  with  which 
the  data  may  be  obtained.  This  impacts  the  NTIP  System  in  the  area  of  content 
generation.  The  NTIP  System,  then,  must  improve  the  form  and  content  of  the 
engineering/manufacturing  data  base  so  that  it  can  be  more  efficiently  converted 
to  technical  information. 

Use  of  the  3-M  Data  Base  - The  primary  concern  here  is  to  maximize  the 
impact  of  this  avenue  of  feedback  from  the  user  to  the  NTIP  System.  Currently, 
the  Maintenance  Material  Management  (3-M)  reports  do  not  reflect  user  awareness 
of  the  potential  these  reports  have  for  providing  feedback  concerning  the  usability 
of  TMs.  The  requirement  thus  imposed  upon  the  NTIP  System  is  one  of  determining 
how  to  maximize  the  utility  (to  TMs)  of  the  data  already  in  the  3-M  data  base,  as 
well  as  to  enhance  the  future  utility  of  the  3-M  system  through  improved  recording 
of  specifics  concerning  TMs. 
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Section  2 - NTIPS  Requirements 


2.2  DESCRIPTION  OF  SYSTEM  FUNCTIONAL  REQUIREMENTS 


The  NTIPP  Task  2 Report  detailed  the  functional  requirements  to  which  the  prelimin- 
ary NTIP  System  concept  and  alternatives  must  respond.  The  following  is  a refinement 
of  those  functional  requirements  based  on  research  conducted  to  date. 


An  NTIP  system  configuration  (Figure  2-1)  was  synthesized  from  a logical 
analysis  of  the  functions  required  and  their  allocation  to  a subsystem  organization. 
This  configuration  is  intended  to  meet  both  the  system-level  requirements  (Topic 
2.1)  and  the  functional  requirements  stated  below.  Consequently,  it  is  the  founda- 
tion upon  which  the  preliminary  system  concept  and  alternatives  described  in  this 
report  have  been  structured. 

Management  Subsystem  - The  Management  Subsystem  is  responsible  for 
analyzing,  coordinating,  and  controlling  the  overall  operation  of  the  NTIP  System. 
In  order  to  accomplish  this,  the  following  requirements  must  be  met. 

1.  The  Management  Subsystem  must: 

• Be  organized  to  provide  for  both  systems  management  and  operations 
management  functions. 

• Develop  top  level  policies  and  procedures  for  all  facets  of  system 
operation. 

2.  The  system  management  function  must; 

• Provide  a command  structure  with  the  authority  to  manage,  control, 
coordinate,  and  monitor  overall  system  operation. 

• Establish  policies  to  guide  system  operation  that  are  in  concert  with 
DoD  policies  for  the  acquisition  of  TMs. 

• Administer  Navy  TM-related  research  and  development  activities 
and  maintain  liason  with  other  DoD  service  branches  and  industry. 

• Conduct  cost  analysis/forecasting  and  reporting  in  the  area  of  TM 
life-cycle  costs  and  NTIPS  costs. 

• Maintain  a comprehensive  and  accurate  Management  Information 
System  (MIS). 

• Provide  for  staffing  of  all  TM  activities. 

• Budget  and  distribute  TM  acquisition  and  system  O&AIN  funds. 

• Administer  system/product  improvement  engineering  activities. 

3.  The  operations  management  function  must: 

• Develop  and  implement  standard  information  reporting/gathering 
mechanisms. 

• Monitor  and  evaluate  subsystem  operations  and  implement  changes 
to  improve  both  cost  and  performance  effectiveness. 

• Develop  standardized  procedures  to  guide  operation  of  NTIPS 
subsystems. 

• Provide  for  accurate  TM  configuration  accounting. 

• Monitor,  evaluate,  and  respond  to  user  feedback  information. 

• Prioritize  and  initiate  all  TM  updating  actions. 

• Provide  guidance  to  hardware  acquisition  activities  on  all  TM-related 
matters. 

TM  Acquisition  Subsystem  - The  TM  Acquisition  Subsystem  provides  the 
definitive  guidelines  for  the  TM  procurement,  and  insures  that  these  guidelines  are 
met  during  the  actual  writing  effort.  It  must  meet  the  following  requirements. 

1.  The  TM  Acquisition  Subsystem  must: 

• Be  organized  to  provide  user-data  match,  specification,  and  procure- 
ment functions. 
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• Be  capable  of  identifying,  specifying,  and  procuring  TMs  that  respond 
to  the  requirements  established  by  the  system  acquisition  process/lLS 
structure. 

2.  The  user-data  match  function  must: 

• Select  TM  presentation  techniques  for  individual  procurements  that 
will  result  in  maximized  TM  effectiveness  for  the  user  based  upon 
the  following  variables; 

- Personnel  characteristics 

- Equipment/system  type 

- Environmental  constraints 

- Tasks  to  be  performed 

• Specify  guidelines  for  conduct  of  Training/Technical  Manual 
tradeoffs. 

• Insure  that  decisions  affecting  TM  development  and  training  are  based 
on  the  most  complete  and  accurate  LSA  information. 

3.  The  TM  specification  function  must: 

• Provide  requirements  for  validation  and  verification  of  TMs: 

- Criteria 

- Scheduling 

- Equipment  required 

- Record  keeping 

• Provide  comprehensive  quality  assurance  procedures  for  content  gen- 
ation,  in  accordance  with  readability,  comprehensibility,  accuracy, 
and  usability  guidelines  developed  to  achieve  user-data  match. 

• Provide  for  logical  arrangement  of  TM  content  for  ease  of  use. 

• Provide  for  fast  and  easy  access,  comprehensive  indexing,  and  simp- 
lified, as  well  as  descriptive,  numbering/divisions/titles/headings. 

• Provide  for  flexibility  and  variety  of  types  and  fonts,  explici*  covers, 
paper  and  film  grades,  TM  sizes,  and  packaging  techniques  for  user 
need  and  environmental  conditions. 

• Provide  guidance  in  the  preparation  of  text  and  procedures  for  var- 
ious equipment  complexities  vs.  amount  of  built-in-test  features  and 
relationships  to  maintenance  philosophy  and  user  skill  levels. 

• Provide  flexibility  and  guidance  in  the  use  of  existing  media  present- 
ation methods  such  as  hard  copy,  microforms,  audio-visual,  or  digital 
devices. 

• Provide  definitive  guidance  in  the  requirements  for  TM  structure  and 
the  inclusion  of  various  presentation  techniques  defined  by  user  infor- 
mation needs,  format  used,  equipment  complexity  and  intended  ''n- 
vironment  of  use. 

• Provide  coordination  and  requirements  for  timely  generation  and 
structure  of  material  for  multi-usage  o^  TM  in  training  classes. 

4.  The  TM  procurement  function  must: 

• Evaluate  data  requirements  of  hardware  acquisition  activities. 

• Determine  total  TM  requirements. 

• Evaluate  proposals  and  select  appropriate  content  generator. 

• Prepare  TM  relevant  sections  of  contract. 

• Provide  quality  assurance  teams  to  evaluate  TM  products. 

• Define  schedules  for  in-process  reviews  and  define  sample  lots  to 
be  inspected. 
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Section  2 - NTIPS  Requirements 


2.2  DESCRIPTION  OF  SYSTEM  FUNCTIONAL  REQUIREMENTS  (Continued) 


Content  Generation  Subsystem  - The  Content  Generation  Subsystem  pro- 
vides the  necessary  capabilities  to  effectively  estimate  the  total  effort  required 
to  produce  the  TM,  to  develop  a plan  for  its  production,  and  then  execute  the  writ- 
ing tasks.  To  do  this,  the  subsystem  must  meet  the  following  requirements: 

1.  The  Content  Generation  Subsystem  must: 

• Be  organized  to  provide  for  estimating,  planning,  and  writing  functions. 

• Provide  quality  assurance  (in-process  monitoring  and  final  product 
review)  using  developed  tools  (formulas,  checklists,  statistical  samp- 
ling techniques,  etc.)  to  insure  compliance  with  established  require- 
ments. 

• Maintain  capability  to  deliver  TMs  within  contractual  time  constraints. 

2.  The  estimating  function  must: 

• Provide  accurate  estimates  for  producing  TMs: 

- Cost 

- Labor 

- Materials 

- Schedules 

3.  The  planning  function  must: 

• Develop  TM  planning  and  design  disclosure  documents  that  are  fully 
detailed  and  customized  to  a particular  system/equipment  based  on 
the  content  generator  interface  with  training,  maintenance  engineer- 
ing, provisioning,  and  design  engineering. 

4.  The  writing  function  must: 

• Provide  the  capability  to  develop  technical  information  within  estab- 
blished  performance  measures  (such  as  man-hours  per  page-unit) 
based  on  the  following: 

- Presentation  Techniques  (FOMM,  JPA,  etc.). 

— System/equipment  types  and  complexity  (electronic,  mechanical, 
etc.) 

- Technical  information  category  (theory  of  operation,  trouble- 
shooting, etc.). 

- Technical  information  types  (narrative,  procedural,  graphics,  etc.). 

• Develop  new  and  updated  TMs  in  compliance  with  data  acquisition 
contractual  requirements  (CDRLs,  DIDs,  TMCRs,  specifications,  and 
standards). 

• Develop  and  validate  procedural  data  using  actual  hardware  to  be 
deployed  in  the  field. 

• Select  writers  based  on  match  of  the  writer's  capabilities/experience 
to  the  writer's  task. 

• Provide  for  a working  interface  with  design  engineers. 

• Manage  and  monitor  development  of  TMs  by  subcontractors  (data 
houses)  and  equipment  vendors. 

• Conduct  IPRs. 

• Compile  and  disseminate  program  historical  data,  including  costs. 

• Provide  technical  information  in  standardized  form  acceptable  to 
digital  production  function  of  Publishing  Subsystem. 

Publishing  Subsystem  - This  subsystem  provides  the  necessciry  capability 
to  convert  the  TM  manuscript  into  a prescribed  medium,  and  distribute  copies  to 
the  designated  user.  The  Publishing  Subsystem  must  meet  the  following  requirements: 
1.  The  Publishing  Subsystem  must: 

• Be  organized  to  provide  digital  production,  mastering,  replication, 
and  TM  supply  funciions. 
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• Provide  a netted,  centrally  controlled,  localized  structure  of  publish- 
ing capabilities  with  common  standards,  policies  and  procedures. 

• Provide  a continuing  technology  assessment  operation  in  disciplines 
related  to  TM  production. 

• Provide  quality  assurance  of  products  and  processes. 

2.  The  digital  production  function  must: 

• Provide  the  ability  to; 

- Enter  text  and  tabular  material  interactively  or  in  a batch  mode 
in  an  automated  system. 

- Enter  graphic  material  interactively  or  in  a batch  mode  in  an  auto- 
mated system. 

- Edit,  update,  and  format  text,  tabular,  and  graphic  material  in  an 
interactive  mode  in  an  automated  system. 

— Store  sufficient  data  in  working  storage  to  meet  work-in-process 
needs. 

— Output  in  digital  form,  the  structured  TM  for  conversion  into  media 
such  as,  hardcopy,  microfilm,  video  disc,  or  holograms. 

• Provide  the  ability  to  accept  from  contractors  such  input  as: 

- Text  material  in  digital  form  (with  and  without  graphics)  on  mag- 
netic tape  (reel,  cassette,  cartridge),  diskette,  paper  tape,  as  repro 
copy  (with  and  without  graphics),  or  copy  prepared  for  optical  char- 
acter recognition  (OCR). 

-Graphic  material  in  digital  form  (image  or  intelligent  form,  separate  from 
text)  on  magnetic  tape  (reel  or  diskette),  as  repro  or  original 
artwork. 

3.  The  mastering  function  must: 

• Convert  digital  output  into  such  media  as  repro  copy,  microform 
master,  printing  plate,  video  disc  master,  or  hologram  master. 

4.  The  replication  function  must; 

• Convert  microform  masters,  reproducible  copy,  and  lithographic  neg- 
atives to  printing  plates  using  contact  and  projection  photographic/ 
imaging  means. 

• Print,  collate,  and  bind  using  conventional  devices. 

• Convert  reproducible  copy  to  microform  masters  using  conventional 
photographic  means. 

• Replicate  from  microform  masters  and  digital-form  masters,  as 
required. 

5.  The  TM  supply  function  must: 

• Provide  the  capability  to  deliver  (to  the  user)  new  and  updated  TMs 
from  distribution  inventories,  using  the  selected  media. 

Distribution  Subsystem  - The  distribution  subsystem  administers  the  distri- 
bution of  new  manuals,  and  the  storage,  retrieval  and  distribution  of  all  previously 
deployed  manuals.  To  accomplish  this,  it  must  meet  the  following  requirements. 

1.  The  Distribution  Subsystem  must: 

• Be  organized  to  provide  initial  distribution  control,  TM  resupply,  and 
archive  functions. 
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Section  2 - NTIPS  Requirements 


2.2  DESCRIPTION  OF  SYSTEM  FUNCTIONAL  REQUIREMENTS  (Continued) 


2.  The  initial  distribution  control  function  must: 

• Collect  and  assimilate  requirements  for  the  first-time  distribution 
of  new  TMs. 

• Maintain  address  files  for  the  automatic  distribution  of  TM  changes 
and  revisions. 

3.  The  TM  resupply  function  must: 

• Maintain  proper  TM  storage  levels  for  user  requriements. 

• Provide  facilities  for  receipt,  storage,  and  retrieval  of  all  supplies 
of  deployed  Navy  TMs  and  establish  procedures  for  user  access. 

4.  The  archive  function  must: 

• Provide  a centrally  controlled  multimedia  storage  facility  for  both 
active  and  inactive  data  banks. 

• Establish  procedures  and  facilities  for  the  receipt,  storage,  and 
retrieval  of  TM  masters. 
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Figure  2-1.  NTIPS  Functional  Block  Diagram 
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Section  2 - NTIPS  Requirements 


J 2.3  DESCRIPTION  OF  SYSTEM  OPERATIONAL  SEQUENCE 


Operational  Sequence  Diagrams  (OSDs)  were  developed  to  confirm  that  the  NTIP  System 
configuration  was  based  on  consistent  operational  assumptions  of  product  development. 

A complex,  interrelated  sequence  of  events  takes  place  among  the  main 
functional  elements  of  the  NTIP  System,  as  a result  of  decisions  to  acquire  new 
systems  or  equipment  items  for  which  NTIPS  has  technical  manual  responsibility. 

To  insui'e  that  the  proposed  NTIP  System  configuration  is  compatible  with  this  se- 
quence of  events,  a set  of  operational  sequence  diagrams  (OSD)  was  developed. 

These  OSDs  illustrate  the  sequence  of  events  beginning  with  the  initiation  of  a TM 
procurement  and  ending  with  the  distribution  of  the  resulting  TM  to  the  user.  On- 
going activities  such  as  system  monitoring,  TM  resupply,  and  processing  of  feedback 
reports  are  also  included. 

A set  of  three  diagrams  was  required  to  fully  describe  NTIPS  sequences: 

• NTIPS  Functional  Sequence 

• General  Operational  Sequence  for  the  NTIP  System 

• Operational  Sequence  for  TM  Development 

An  example  of  part  of  the  TM  development  sequence  diagram  is  reproduced  in  Fig- 
ure 2-2.  The  complete  set  of  diagrams  and  a detailed  explanation  is  located  in 
Appendix  D of  this  report. 
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Section  3 - Preliminary  NTIP  System  Concept 


3.1  SYNOPSIS  OF  PRELIMINARY  NTIP  SYSTEM  CONCEPT 


the  preliminary  NTIP  System  concept  takes  full  advantage  of  existing  Tectmical  Manual 
expertise  within  Navy  organizations,  while  allocating  new  responsibilities  and  functions 
to  these  organizations.  The  concept  is  a union  of  existing  Navy  TM  activities  that  are 
refocused  and  complemented  by  new  technologies  to  better  serve  the  information  needs 
of  the  user. 

The  preliminary  N TIP  System  concept  (see  Figure  3-1)  is  an  integrated  net- 
work of  Navy  and  contractor  organizations  as  well  as  a set  of  procedures  and  tech- 
nological recommendations  for  the  acquisition  and  support  of  technical  information 
for  use  in  operating,  maintaining,  training,  and  logistic  support  for  Navy  Systems 
and  equipment.  The  NTIP  System  configuration  was  synthesized  from  a logical  anal- 
ysis of  the  functions  required  and  their  allocation  to  subsystems.  Five  subsystems 
resulted:  Management,  TM  Acquisition,  Content  Generation,  Publishing,  and  Distri- 
bution. Ihese  subsystems  invoke  a variety  of  human  actions,  mechanical  operations, 
ana  matiagement  processes.  Hence,  a broad  range  of  technical  approaches  reside 
m the  preliminary  NTIP  System  concept. 

Management  Subsystem  - The  first-level  systems  management  function 
is  comprised  of  four  subfunctions.  The  NTIP  System  management  subfunction  is 
responsible  for  the  overall  management  of  NTIPS,  and  establishes  and  promulgates 
all  policies  and  directives  necessary  for  system  operation.  The  system/product 
improvement  engineering  subfunction  performs  in-depth  analyses  of  budgeting  and 
scheduling  data  from  Navy-wide  NTIPS  activities,  analyzes  TM  product  quality, 
provides  the  engineering  expertise  for  changes  to  NTIP  System  technology  or  de- 
sign, and  prepares  all  quality  assurance  policies  for  the  NTIP  System.  The  research 
and  development  (R&D)  subfunction  coordinates  all  Navy  NTIPS-related  R&D  ef- 
forts and  maintains  contacts  with  on-going  DoD  and  industry  TM  R&D  efforts. 

The  cost  analysis/  forecasting  subfunction  maintains  a comprehensive  data  base 
of  cost  breakdowns  for  specific  activities  of  NTIPS,  and  also  assists  with  budget 
reviews  and  long-range  planning  and  forecasting. 

Ihe  operations  management  function  consists  of  six  subfunctions.  The 
operations  management  subfunction  is  responsible  for  implementing  first-level 
policies,  promulgating  detailed  operating  procedures  to  its  NTIPS  activities,  and 
guiding  the  operations  of  the  NTIPS  activities  within  its  purview.  The  practices 
and  procedures  subfunction  prepares  the  detailed  operating  procedures  and  main- 
tains the  manuals  containing  the  procedures,  practices,  and  the  first-level  policies. 
The  Management  Information  System  (MIS)  subfunction  maintains  a data  base  of 
information  covering  TM  operations  and  costs,  a TM  configuration  index  of  all 
assigned  users,  and  a listing  of  user  feedback  action  items.  The  MIS  also  provides 
weekly  cost  and  operations  reports  to  support  the  daily  operations  of  the  remaining 
NTIPS  subsystems. 

The  configuration  accounting  subfunction  manages  the  numbering  of  TMs 
and  maintains  the  user  configuration  index.  The  feedback  and  update  subfunction 
manages  the  user  feedback  network  and  initiates  updates  of  out-of-production  TMs. 
The  cost  monitor/evaluation  subfunction  collects  operational  data  from  the  NTIPS 
activities  and  evaluates  the  performance  of  specific  TM  projects. 

TM  Acquisitioti  Subsystem  - The  preliminary  concept  for  TM  acquisition 
is  that  of  decentralized  subsystems  within  the  NTIPS  that  are  dedicated  to  each 
major  acquisition  activitiy.  These  subsystems  would  specify  precise  TM  require- 
ments for  their  particular  users  and  implement  procurement  procedures  to  ensure 
timeliness  and  quality  in  TMs. 
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I'he  I'M  Acquisition  Subsystem  analyzes  the  initial  data  requirements  I'or 
a r.vi  procurement,  performs  a user-data  match,  selects  specifications  that  precisely 
define  the  TM  requirements,  develops  contract  documents,  and  initiates  the  acqui- 
sition processes  to  purchase  1 Ms  from  the  content  generators. 

New  concepts  for  the  TM  Acquisition  Subsystem  would  include:  (1)  formal 
matching  of  the  data  to  the  particular  user,  (2)  automated,  modular  TM  specifica- 
tions, (3)  f.M  procurement  activities  that  are  run  by  specialized  "Navy  TM  fingi- 
neers,"  and  (4)  new  TM  funding  structures.  TM  acquisition  is  the  place  where  many 
TM  problems  can  be  solved,  long  before  TM  production  is  initiated.  Improper  de- 
; eisions  on  data  requirements,  TM  specifications,  and  procurement  actions  in  this 

subsystem  will  result  in  substandard  TMs  downstream. 

The  preliminary  concept  of  the  user-data  match  function  is  to  match  a spe- 
cified user's  information  needs,  based  on  the  tasks  he  must  perform  on  particular 
equipments  in  known  environments,  to  the  information  types  and  presentation  tech- 
niques he  can  best  utilize  to  perform  the  tasks.  The  tool  for  making  this  determina- 
: tion  is  a sot  of  matrices  tliat  form  the  user-data  match  model  (i.e.  the  matrices 

/ plotting  task  action  versus  presentation  components,  and  environment  versus  physical 

characteristics  of  media). 

^ The  output  of  the  user-data  matching  process  would  consist  of  a prioritized 

? list  of  requirements  and  recommendations  concerning  the  media  and  presentation 

I techniques  to  be  employed  in  presenting  technical  information  (for  every  task  ac- 

tion) to  the  user.  This  information  would  be  forwarded  to  the  Navy  TM  engineer, 
who  would  then  select  the  presentation  techniques  and  media  features  to  be  speci- 
fied for  the  TM  procurement.  This  selection  would  be  based  upon  the  affordability 
' of  the  requirements/recommendations  for  that  procurement. 

The  TM  specification  function  selects  specifications  that  define  the  content, 
quality  control  provisions,  and  standards  that  must  be  achieved  in  the  development 
i of  TMs.  The  preliminary  concept  proposes  a T!M  specification  function  within  the 

N llPS  organizational  structure  that  is  dedicated  to  each  major  acquisition  activity. 
Each  of  these  functions  would  utilize  an  automated,  modular,  TM  specification  struc- 
ture. Specification  modules  would  be  combined  as  necessary  to  describe  the  com- 
plete requirements  for  a particular  TM  procurement,  including  publishing  processes 
for  various  media,  quality  control  guidelines,  etc. 

The  TM  procurement  function  is  responsible  for  negotiating  the  purchase 
of  the  TM.  It  develops  TM  contract  documents,  participates  in  negotiations  with 
content  generators,  and  provides  quality  control  of  the  TM  development  process, 
all  the  way  to  the  final  buyoff.  A procurement  and  funding  structure  is  conceived 
that  would  prohibit  reallocation  of  funds  that  have  been  dedicated  to  TMs. 

Content  Generation  Subsystem  - The  Content  Generation  Subsystem  repre- 
sents the  most  significant  and  final  point  of  impact  on  technical  information  qual- 
ity. The  content  generator  is  resonsible  for  collecting  the  data,  estimating  the  pro- 
posed TM  acquisition  cost,  preparing  technical  publications  planning  documents, 
writing  the  TM,  critiquing  the  TM,  and  performing  validation.  Guided  by  the  data 
acquisition  rules,  the  content  generator  performs  the  human  transformation  of  the 
engineering/manufacturing  data  base  into  technical  information. 

The  engineering/manufacturing  data  base  is  critical  to  the  content  generator 
because  it  is  the  sole  source  of  system/equipment  descriptions.  The  major  problems 
associated  with  the  data  base  are  limited  content  (e.g.,  no  maintenance  data),  ac- 
curacy and  currentness.  The  preliminary  concept  would  solve  these  problems  by 
I modifying  the  data  base  content  requirements  to  add  maintenance  data,  and 
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employing  automated  equipment  to  eliminate  the  time  consuming  and  error  prone 
manual  methods  for  developing,  checking,  reproducing,  and  distributing  the  data 
base. 

The  Content  Generation  Subsystem  consists  of  three  functions  (estimating, 
planning,  and  writing).  The  functions  apply  to  both  Navy  in-house  and  contractor 
content  generation  activities.  In  addition,  the  preliminary  concept  would  establish 
a TM  engineering  position  which  impacts  all  tasks  of  each  function.  The  TM  engi- 
neer provides  for  planning  and  technical  guidance  throughout  the  TM  program.  He 
is  responsible  for  collecting  the  data,  developing  the  TM  estimates,  preparing  a 
detailed  TM  book  plan,  writing  the  TM,  technically  critiquing  the  TM,  and  performing 
validation.  He  is  also  responsible  for  establishing  a discourse  between  the  writers 
and  instructors,  as  well  as  insuring  that  the  engineering/manufacturing  and  logistic 
data  base  information  is  available.  He  confirms  the  optimum  presentation  methods 
identified  by  the  user-data  match  model,  allocates  writer  tasks,  and  insures  con- 
tent quality.  The  TM  engineer  also  establishes  interrelationships  with  the  design 
engineering  activity  and  the  ILS  elements  to  insure  coordinated  efforts  in  TM 
development. 

To  aid  the  TM  engineer  in  performing  his  tasks,  detailed  guidance  in  the 
form  of  a TM  Development  Guide  would  be  provided  as  part  of  the  preliminary  con- 
cept. This  guide  provides  step-by-step  instructions  for  the  development  of  TM  esti- 
mates and  planning  documents  as  well  as  for  coordinating  and  supervising  the  actual 
TM  development. 

Estimating  Function  - An  estimate  is  developed  for  each  TM  preparation 
effort  based  on  the  results  of  the  analysis  of  the  TM  requirements  and 
system/equipment  design  information.  The  estimate  provides  the  TM  Ac- 
quisition Subsystem  with  a detailed  description  of  the  cost  and  effort  that 
would  be  incurred  for  the  proposed  TM. 

Planning  Function  - The  planning  function,  which  encompasses  the  content 
generator's  total  planning  effort,  is  divided  into  product  planning  and  oper- 
ational planning  subfunctions.  Product  planning  deals  with  those  tasks  re- 
lated to  the  development  of  accurate  and  detailed  TM  bookplans  and  out- 
lines. Operational  planning  covers  those  tasks  related  to  the  actual  technical 
data  development;  applying  the  content  generator's  resources  in  the  most 
efficient  manner  to  prepare  accurate  and  adequate  technical  data. 

Writing  Function  - The  content  generator  prepares  the  technical  information 
in  accordance  with  the  directives  and  instructions  developed  in  the  planning 
function.  Any  writer  training  plans,  prepared  during  operational  planning, 
are  implemented  to  upgrade  the  writing  staff's  capabilities.  In  the  tradi- 
tional writing  effort,  conflicting  comments  that  result  from  independent 
TM  manuscript  reviews  by  the  TM  acquisition,  design  engineering,  and  train- 
ing activities  cause  severe  problems.  These  problems  are  resolved  in  the 
preliminary  concept  by  performing  a concurrent  review  and  validation,  with 
participation  by  all  these  activites  including  the  user  activity.  Quality  as- 
surance personnel  monitor  the  progress  of  the  writing  effort,  review  writer 
draft  material,  and  generate  and  submit  progress  reports  to  the  TM  Acqui- 
sition Subsystem.  Included  in  these  reports  are  the  technical  information 
development  problems  that  have  been  encountered,  and  their  solutions. 

Direct  Navy  participation  in  contractor  writing  efforts  consists  of  performing 
in-process  reviews  (IPRs)  of  writer  draft  TM  material  and  participating 
in  the  concurrent  TM  manuscript  review  and  validation  performed  by  the 
contractor. 
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Publishing  Subsystem  - The  preliminary  concept  for  publishing  provides 
decentralized  internal  Navy  capabilities  to  accept  the  equipment  contractor's  digital 
output  for  processing  through  production,  mastering,  replication,  and  final  delivery. 

A feature  of  this  concept  is  automated  facilities  to  process  new  and  updated  text 
and  graphics. 

The  digital  production  function  contains  the  entry,  processing,  and  storage 
subfunctions.  The  entry  subfunction  provides  the  capability  to  receive  technical 
information  generated  both  by  equipment  contractors  and  internal  Navy  content 
generation  activities,  and  to  edit,  update,  and  process  the  technical  information 
for  mastering  of  TMs. 

The  mastering  function  converts  the  processed  output  to  masters  (making 
the  master  for  replication  such  as:  repro  copy,  negative,  or  microform  masters). 

This  function  must  be  able  to  accommodate  paper  and  microform.  The  replication 
function  contains  the  subfunctions  needed  to  replicate  the  medium  selected. 

The  TM  supply  function  provides  the  capability  for  packaging  and  shipping 
new  and  updated  TMs  in  response  to  distribution  requirements  provided  by  the  Dis- 
tribution Subsystem. 

The  Publishing  Subsystem  would  be  decentralized  among  the  major  acquisi- 
tion activities.  The  functions  established  for  each  major  acquisition  activity  could 
be  organizationally  either  part  of  that  activity  or  part  of  the  NTIP  System,  but  dedi- 
cated to  the  major  acquisition  activity.  There  is  a need  to  distribute  functions  on 
the  basis  of  the  amount  of  work  to  be  processed  annually  (3  to  4 million  pages)  plus 
the  size  of  the  TM  inventory  (25  million  TM  pages).  These  divisions  can  be  made 
by  specific  commodity  to  be  supported,  assigned  missions,  geographical  locations, 
or  similar  factors. 

Technology  and  industry  development  trends  show  that,  in  the  1980-85  time 
frame,  digital  processing  of  text  and  graphics  may  reach  full  implementation  through- 
out the  publishing  field.  Those  who  support  Navy  TM  requirements,  including  the 
very  small  Navy  contractor,  will  either  possess,  or  have  access  to,  an  automated 
digital  publishing  capability.  Therefore,  any  requirement  for  contractors  to  deliver 
machine  readable  (digital  tape)  technical  information  to  the  Navy  can  be  met. 

The  Navy  has  progressed  significantly  in  the  area  of  automation  as  evidenced 
by  ADREPS  and  TRUMP.  The  Publishing  Subsystem  must  accommodate  both  of 
these  systems  by  bringing  them  to  a level  of  performance  that  meets  the  Navy/ 
Contractor  interface  requirements  and  can  handle  the  type  and  volume  of  work 
expected  by  NTIPS.  An  alternative  would  be  to  develop  totally  new  systems.  Since 
some  additional  capability  is  needed  to  meet  the  expanded  internal  workload,  new 
systems  using  the  latest  technology  are  a consideration. 

Distribution  Subsystem  - The  task  of  the  initial  distribution  control  function 
is  to  collect  the  information  necessary  to  create  shipping  directives  for  newly  ac- 
quired TMs  and  TM  changes  and  revisions.  In  the  preliminary  concept,  initial  distri- 
bution control  is  decentralized,  with  one  initial  control  function  dedicated  to  each 
major  acquisition  activity.  This  eliminates  the  response  problems  inherent  in  a 
totally  centralized  system  and  utilizes  existing  Navy  facilities. 

A standardized  approach  to  the  collection  of  complete  and  accurate  initial 
distribution  information  mast  be  created  if  new  TMs,  changes,  and  revisions  are 
to  be  delivered  in  a timely  manner.  The  key  to  accomplishing  this  is  the  creation 
and  maintenance  of  a computerized  distribution  address/quantity  file.  With  over 
140,000  TMs  in  the  Navy's  inventory,  and  with  as  many  as  30,000  new  TMs,  changes, 
and  revisions  being  processed  each  year,  it  is  estimated  that  this  file  will  require 
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[ A Storage  capacity  of  approximately  2.8  billion  bits  to  maintain  the  data  on  the  num- 

I ber  of  TMs  and  addresses  in  the  TM  inventory. 

The  resupply  function  would  be  a single,  centralized  I'M  supply  activity, 
ij  The  concept  being  proposed  here  is  that  it  would  be  a functional  part  of  the  N'l'lPS 

/ Distribution  Subsystem.  This  will  allow  the  producers  of  TMs  (i.e.  NTIPS)  more 

! direct  control  of  the  supply  of  manuals  to  fleet  users.  It  would  provide  central  stor- 

i age,  retrieval,  and  control  for  all  Navy  TMs  in  a variety  of  media.  Information  man- 

agement, control,  and  reporting  will  be  automated  as  an  element  of  MIS. 

The  initial  concept  of  the  archive  function  would  establish  capabilities  for 
the  storage,  retrieval,  and  control  of  all  masters  and  master  records  of  TMs  deployed 
by  the  Navy.  The  archive  function  would  consist  of  an  historical  and  working  ar- 
chive. The  historical  archive  will  provide  for  storage  and  accountability  of  the  phys- 
ical TVl  masters  for  every  new  or  updated  TM.  The  working  archive  will  be  primarily 
a digital  data  base  only  for  the  active  TMs  in  the  Navy's  inventory.  It  would  be 
used  for  replenishment  of  stock,  or  update  of  existing  TMs  without  disturbing  the 
historical  archive. 

The  initial  loading  of  the  working  archive  data  base  with  1 Ms  received  from 
contractors  or  prepared  by  Navy  content  generators  is  accomplished  through  the 
digital  production  function  of  the  Publishing  Subsystem.  This  input,  and  any  sub- 
sequent moving  of  TMs  to  be  reprocessed  between  the  Publishing  Subsystem  and 
the  working  archive,  is  controlled  through  the  MIS.  MIS  also  provides  NTIPS  with 
access  to  an  index  of  information  on  any  active  TM  in  the  Navy. 

New  TM  masters  are  sent  to  the  historical  archive  from  the  Publishing  Sub- 
system. As  the  subfunction  is  primarily  a materials  managemeni  activity,  the  MIS 
computer  network  will  be  used  for  creation  and  maintenance  of  records  for  control 
of  the  TM  masters.  Physical  storage  procedures  will  depend  upon  the  media  in 
which  the  masters  have  been  produced.  If  in  a condensed  form,  such  as  microfiche 
or  roll  microfilm,  the  masters  will  be  stored  in  that  medium.  If,  however,  the  mas- 
ters require  bulk  storage,  such  as  reproducible  masters  for  paper  manuals,  they  will 
be  converted  to  a more  condensed  medium  for  storage  in  the  historical  archive  files. 
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Figure  3-1.  Preliminary  NTIP  System  Concept. 
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Section  3 - Preliminary  NTIP  System  Concept 


3.2  TECHNICAL  APPROACH  TO  TM  ACQUISITION  SUBSYSTEM 


The  concept  for  TM  acquisition  proposes  using  a model  to  match  technical  information 
to  the  user,  specifying  requirements  with  custom-tailored,  modular  TM  specifications, 
and  utilizing  a well-defined  TM  procurement  function  to  execute  the  purchase  process. 

Significant  problems  in  the  TM  Acquisition  Subsystem  are:  determining 
the  types  of  technical  information  to  buy,  specifying  the  requirements  for  that  in- 
formation, and  executing  contracts  and  procedures  to  insure  the  timeliness  and  qual- 
ity of  information  that  is  delivered. 

I'he  TM  Acquisition  Subsystem  is  designed  to  solve  these  problems  (see  Table 
3-1).  Subsystem  activities  include:  (1)  an  analysis  of  initial  data  requirements  during 
the  hardware  acquisition  process,  (2)  matching  presentation  techniques  and  media 
features  to  user  needs  and  environmental  conditions,  (3)  maintenance,  preparation, 
and  selection  of  TM  specifications  that  will  give  content  generators  precise  guidance 
in  what  is  required  in  technical  information,  (4)  preparation  of  procurement  docu- 
ments and  participating  in  contractual  processes  for  the  duration  of  the  contract, 
and  (5)  implementation  of  quality  control  plans  and  teams  for  inprocess  reviews 
and  verification.  These  activities  are  performed  by  the  user-data  match,  TM  speci- 
fications, and  TM  procurement  functions. 

Approach  to  User-Data  Match  - Navy  operation  and  maintenance  personnel 
are  being  supplied  technical  information  that  does  not  fully  support  them  in  per- 
forming their  tasks.  The  major  problems  arise  from  inappropriate  information  for 
the  user  to  perform  his  tasks  and  misapplication  of  presentation  techniques  and 
media  for  conveying  the  information.  One  element  of  the  NTIPS  approach  to  this 
problem  is  the  user-data  match  model.  The  model  will  assimilate  user  personnel 
characteristics,  user  task  and  equipment  analyses,  presentation  techniques,  and 
media  considerations  for  environmental  factors  into  a set  of  matrices  that  will  aid 
in  the  selection  of  user-optimized  presentation  techniques.  These  models  will  iden- 
tify the  best  media  form  for  a particular  technician  to  utilize  in  performing  specific 
tasks  on  particular  equipment  under  different  environmental  conditions. 

Approach  to  TM  Specification  - Most  TM  specifications  presently  used  employ 
a "cover  the  world"  approach,  attempting  to  describe  in  one  place  all  TM  require- 
ments for  mechanical,  electrical,  electronic,  and  hydraulic  equipment  to  be  used 
by  organizational,  intermediate,  and  depot  personnel.  Also,  there  is  often  a vast 
"daisy-chain"  in  TM  specifications,  involving  as  many  as  a dozen  different  documents 
in  a particular  TM  procurement.  When  the  requirements  of  some  of  these  specifi- 
cations are  invoked  in  whole  or  part,  while  others  are  superseded  or  canceled  in 
whole  or  part,  it  becomes  very  confusing  for  content  generators  to  decide  what 
is  really  needed  or  wanted  in  a TM.  Finally,  updating  of  specifications  is  frequently 
several  years  behind  the  required  change,  resulting  in  additional  mismatching  of 
TM  content  and  user  need. 

The  solution  to  these  TM  specification  problems  involves  determining  what 
is  required  in  technical  information  for  various  Navy  users  and  documenting  the 
requirements  in  a flexible  structure  that  can  be  easily  accessed,  formatted,  and 
updated.  Automated,  modular,  TM  specifications  is  the  chosen  approach,  permitting 
TM  requirements  to  be  documented  in  bite-sized  increments,  or  modules.  These 
modules  can  then  be  automatically  selected  and  combined  to  form  a complete, 
custom-tailored  TM  specification  for  a particular  procurement. 

Approach  to  TM  Procurement  - Totally  unrelated  TM  procurement  practices 
and  processes  from  one  major  acquisition  activity  to  the  next  results  in  inefficien- 
cies within  the  Navy  and  their  contractors  such  that  a diversity  of  TMs  with  varying 
degrees  of  usefulness  are  being  introduced  into  the  fleet.  Differences  in  funding 
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practices,  quality  control  methods,  and  delegation  of  authority  also  plague  current 
TM  procurement  functions. 

The  solution  is  to  have  several  TM  procurement  functions,  organizationally 
a part  of  NTIPS,  each  dedicated  to  and  responsible  for  all  matters  relating  to  TM 
procurement  for  a major  acquisition  activity.  This  shifts  responsibility  and  funding 
for  TM  procurement  from  the  hardware  project  office  to  the  NTIPS  TM  procurement 
function.  A new  position  of  "Navy  TM  engineer"  would  also  be  created  to  oversee 
and/or  participate  in  all  activities  for  TM  procurement.  The  Navy  TM  engineer 
would  be  both  a TM  and  QA  specialist  who  would  ensure  that  TM  objectives  are 
being  realized.  He  would  also  disburse  "captured  funds"  for  the  initial  procurement 
and  update  of  TMs. 


I'ABLE  3-1.  APPROACH  TO  TM  ACQUISITION 


Key  Problems 

NTIPS  Approach 

User-Data  Match 

Users  are  not  being  supplied  the 
types  of  technical  information  that  ! 
match  their; 

- skill  levels  I 

- environment 

- operational  and  maintenance  needs 

Development  of  a user-data  match  model 
that  will  specify  the  types  of  data  a spe- 
cific class  of  Navy  user  requires,  by  task 
and  equipment  analysis,  presentation 
techniques,  and  media  for  use  environment 

TM  Specification 

TM  specifications  are  inadequate, 
vague,  and  confusing  in  defining  TM 
I’eruirements  from  one  TM  procure- 
..lent  to  the  next 

Development  of  TM  specification  modules 
with  precisely  defined  requirements  that 
may  be  mixed  and  matched  in  various 
combinations  to  meet  specific  information 
requirements 

I M Procurement  i 

Inadequate  enforcement  of  TM  pro- 
curement requirements  (including 
quality  assurance  provisions)  and 
fragmented  I'M  management  re- 
sponsibilities for  TM  acquisition 

1 

Development  of  a TM  procurement  func- 
tion with  new  organizational  funding 
structures  and  standardization  of  activi-  * 

ties  that  are  controlled  by  a "Navy  TM 
engineer" 
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3,3  TECHNICAL  APPROACH  TO  CONTENT  GENERATION  SUBSYSTEM 


The  main  problems  in  tlie  Content  Generation  Subsystem  are  Ioa'  accuracy  and  effi- 
ciency in  the  transformation  of  technical  data  to  technical  information.  Improvements 
are  accomplished  by  assigning  a I’M  engineer,  using  better  specifications  and  writing 
guides,  and  employing  procedural  reforms. 

Transformation  of  technical  data  to  technical  information  takes  place  in 
the  Content  Generation  Subsystem.  This  subsystem  is  responsible  for  collecting 
the  technical  data,  preparing  TM  estimates  and  planning  documents,  writing  the 
TM,  critiquing  the  TM  and  performing  validation.  The  major  problems  associated 
with  this  subsystem  are  in  the  accuracy  and  efficiency  of  transforming  source  data 
into  the  information  presented  in  the  TM. 

Because  the  engineering/manufacturing  data  base  is  developed  to  satisfy 
the  requirements  of  those  two  disciplines,  it  does  not  adequately  address  the  needs 
of  the  content  generator.  Engineering  drawings  and  specifications,  prepared  for 
liardware  fabrication  and  test,  do  not  contain  needed  maintenance  data.  The  pre- 
liminary concept  would  improve  the  data  base  content  by  modifying  content  require- 
ments (MlL-STD-1 00)  to  include  maintenance  data. 

Also,  manual  methods  employed  to  develop  the  data  base  present  additional 
problems  to  the  content  generator  because  of  the  time-lag  impact  accuracy  and 
currency.  Employing  present-day  capabilities  of  computers  and  their  peripheral 
equipments  would  enable  the  manufacturer  to  reduce  or  eliminate  many  repetitive, 
time-consuming  manual  tasks,  resulting  in  faster  updating  of  the  data  base. 

The  preliminary  concept  would  employ  a TM  engineer  as  one  means  for  im- 
proving the  transformation  process.  He  is  responsible  for  data  collection,  detailed 
TM  book  plan  preparation,  TM  writing,  TM  technical  critique  and  validation  per- 
formance. He  is  also  responsible  for  a cross  fertilization  betwem  the  writers  and 
training  instructors,  as  well  as  ensuring  engineering/manufacturing  and  logistic  data 
base  information  is  available. 

In  the  estimating  function,  little  or  no  coordination  exists  between  the  con- 
tent generator  and  the  design  engineering,  ILS,  and  quality  assurance  activities. 

As  a result,  the  TM  estimate  may  be  inaccurate  in  page  count  and  man-hours  as 
well  as  incompatible  with  other  ILS  element  estimates  (training,  spares  provision- 
ing, etc.),  thus  limiting  the  total  support  package's  ability  to  meet  user  needs.  To 
solve  this  problem,  the  TM  engineer,  acting  as  content  generator  single  point  of 
contact,  works  closely  with  the  hardware  proposal  management  team,  ILS  elements, 
and  the  QA  activity  to  develop  the  TM  estimate  based  on  inputs  from  these  activ- 
ities. The  result  is  an  integrated  and  more  realistic  pricing  estimate  for  the  TM 
contracting  process. 

Two  major  problems  in  planning  the  TM  product  are:  (I)  vague  and  nonde- 
tailed  TM  bookplans  and  outlines,  and  (2)  incompatibility  of  TM  planning  documents 
with  the  other  ILS  elements  planning  documents.  To  deal  with  the  first  problem, 
the  TM  engineer  uses  the  NTlPS-developed  modular  specifications  and  detailed 
system/equipment  descriptions  to  prepare  customized  TM  bookplans  and  outlines. 

The  second  problem  is  solved  by  establishing  an  ILS  review  team  that  reviews  each 
I’M  planning  document  in  light  of  the  overall  integrated  support  effort  and  resolves 
any  conflicts. 

For  operational  planning,  the  major  problem  is  inefficient  transformation 
of  source  data  into  technical  information  for  the  TM  (resulting  from  poor  matching 
of  writers  to  TM  work  packages).  To  solve  this  problem,  the  TM  engineer  identifies 
the  package  requirements  and  writing  staff  capabilities,  then  matches  the  writer's 
capabilities  to  the  work  package  requirements.  If  the  need  exists  to  upgrade  the 
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practices,  quality  cotitrol  methods,  and  delegation  of  authority  also  plague  current 
TM  procurement  functions. 

The  solution  is  to  have  several  TM  procurement  functions,  organizationally 
a part  of  NTIPS,  each  dedicated  to  and  responsible  for  all  matters  relating  to  TM 
procure. nent  for  a major  acquisition  activity.  This  shifts  responsibility  and  funding 
for  I'M  procurement  from  the  hardware  project  office  to  the  NTIFS  T.M  procurement 
function.  A new  position  of  "Navy  TM  engineer"  would  also  be  created  to  oversee 
and/or  participate  in  all  activities  for  TM  procurement.  The  Navy  TM  engineer 
would  be  both  a TMi  and  QA  specialist  who  would  ensure  that  TM  objectives  are 
being  realized.  He  'would  also  disburse  "captured  funds"  for  the  initial  procurement 
and  update  of  TMs. 


TABLE  3-1.  APPROACH  TO  TM  ACQUISITION 


Key  Problems 

NTIPS  Approach 

User-Data  Match  ! 

Users  are  not  being  supplied  the  1 

types  of  technical  information  that 
match  their: 

- skill  levels 

- environment 

- operational  and  maintenance  needs 

Development  of  a user-data  match  model 
that  will  specify  the  types  of  data  a spe- 
cific class  of  Navy  user  requires,  by  task 
and  equipment  analysis,  presentation 
techniques,  and  media  for  use  environment 

TM  Specification 

TM  specifications  are  inadequate, 
vague,  and  confusing  in  defining  TM 
requirements  from  one  TM  procure- 
ment to  the  next 

Development  of  TM  specification  modules 
with  precisely  defined  requirements  that 
may  be  mixed  and  matched  in  various 
; combinations  to  meet  specific  information 
requirements 

TM  Procurement 

Inadequate  enforcement  of  TM  pro- 
curement requirements  (including 
quality  assurance  provisions)  and 
fragmented  TM  management  re- 
sponsibilities for  TM  acquisition 

1 

1 

Development  of  a T.M  procurement  func- 
tion  with  new  organizational  funding 
structures  and  standardization  of  activi- 
ties that  are  controlled  by  a "Navy  TM 
engineer" 
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3.3  TECHNICAL  APPROACH  TO  CONTENT  GENERATION  SUBSYSTEM 


, I'lie  main  problems  in  the  Content  Generation  Subsystem  are  loi(v  accuracy  and  effi- 
ciency in  the  transformation  of  technical  data  to  technical  information.  Improvements 
are  accomplished  by  assi^jning  a I'M  engineer,  using  better  specifications  and  writing 
guides,  and  employing  procedural  reforms. 

Transformation  of  technical  data  to  technical  information  takes  place  in 
the  Content  Generation  Subsystem.  This  subsystem  is  responsible  for  collecting 
the  technical  data,  preparing  TM  estimates  and  planning  documents,  writing  the 
TM,  critiquing  the  TM  and  performing  validation.  The  major  problems  associated 
with  this  subsystem  are  in  the  accuracy  and  efficiency  of  transforming  source  data 
into  the  information  presented  in  the  TM. 

Because  the  engineering/manufacturing  data  base  is  developed  to  satisfy 
the  requirements  of  those  two  disciplines,  it  does  not  adequately  address  the  needs 
of  the  content  generator.  Engineering  drawings  and  specifications,  prepared  for 
hardware  fabrication  and  test,  do  not  contain  needed  maintenance  data.  The  pre- 
liminary concept  would  improve  the  data  base  content  by  modifying  content  require- 
ments (MIL-STD-1 00)  to  include  maintenance  data. 

Also,  manual  methods  employed  to  develop  the  data  base  present  additional 
problems  to  the  content  generator  because  of  the  time-lag  impact  o'"  accuracy  and 
currency.  Employing  present-day  capabilities  of  computers  and  their  peripheral 
equipments  would  enable  the  manufacturer  to  reduce  or  eliminate  many  repetitive, 
time-consuming  manual  tasks,  resulting  in  faster  updating  of  the  data  base. 

The  preliminary  concept  would  employ  a TM  engineer  as  one  means  for  im- 
proving the  transformation  process.  He  is  responsible  for  data  collection,  detailed 
TM  book  plan  preparation,  TM  writing,  TM  technical  critique  and  validation  per- 
formance. He  is  also  responsible  for  a cross  fertilization  between  the  writers  and 
training  instructors,  as  well  as  ensuring  engineering/manufacturing  and  logistic  data 
base  information  is  available. 

! In  the  estimating  function,  little  or  no  coordination  exists  between  the  con- 

tent generator  and  the  design  engineering,  ILS,  and  quality  assurance  activities. 

As  a result,  the  TM  estimate  may  be  inaccurate  in  page  count  and  man-hours  as 
well  as  incompatible  with  other  ILS  element  estimates  (training,  spares  provision- 
ing, etc.),  thus  limiting  the  total  support  package's  ability  to  meet  user  needs.  To 
solve  this  problem,  the  TM  engineer,  acting  as  content  generator  single  point  of 
contact,  works  closely  with  the  hardware  proposal  management  team,  ILS  elements, 
and  the  QA  activity  to  develop  the  TM  estimate  based  on  inputs  from  these  activ- 
ities. The  result  is  an  integrated  and  more  realistic  pricing  estimate  for  thp  T.M 
contracting  process. 

I Two  major  problems  in  planning  the  TM  product  are:  (1)  vague  and  nonde- 

tailed  TM  bookplans  and  outlines,  and  (2)  incompatibility  of  TM  planning  documents 

F with  the  other  ILS  elements  planning  documents.  To  deal  with  the  first  problem, 

the  TM  engineer  uses  the  NTIPS-developed  modular  specifications  and  detailed 
system/equipment  descriptions  to  prepare  customized  TM  bookplans  and  outlines. 
The  second  problem  is  solved  by  establishing  an  ILS  review  team  that  reviews  each 
TM  planning  document  in  light  of  the  overall  integrated  support  effort  and  resolves 
any  conflicts. 

For  operational  planning,  the  major  problem  is  inefficient  transformation 
of  source  data  into  technical  information  for  the  TM  (resulting  from  poor  matching 
of  writers  to  TM  work  packages).  To  solve  this  problem,  the  TM  engineer  identifies 
the  package  requirements  and  writing  staff  capabilities,  then  matches  the  writer's 
capabilities  to  the  work  package  requirements.  If  the  need  exists  to  upgrade  the 
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staff's  capabilities  to  make  satisfactory  matches,  the  TM  engineer  has  the  option 
of  employing  graduate  engineers  trained  in  technical  writing,  providing  equipment 
"hands-on"  experience,  or  conducting  writer  training  courses. 

In  the  writing  function,  the  current  review  and  validation  processes  do  not 
effectively  measure  TM  content  completeness,  technical  needs,  or  user  effective- 
ness. The  preliminary  concept  combines  the  design  engineer's  technical  review, 

TIvl  acquisition's  review,  and  TVi  validation  into  a single  effort,  enabling  all  TM  pro- 
gram participants  to  achieve  consensus  as  i body  in  the  resolutio  i of  Tvi  problems. 

Another  problem,  not  related  to  a specific  NTIPS  function,  is  that  there 
is  no  means  for  evaluating  a recently  completed  TM  acquisition  program  to  identify 
future  improvements.  As  a result,  the  Navy  TM  acquisition  effort  does  not  benefit 
from  past  problems  and  solutions.  The  preliminary  concept  establishes  a post- 
program review  to  evaluate  each  program  and  its  problems  and  their  solutions,  from 
which  recommendations  are  submitted  to  the  TM  Acquisition  Subsystem  for  review 
and  action. 

To  aid  the  TiM  engineer  in  performing  his  duties,  he  would  be  provided  with 
a TM  Development  Guide.  This  guide  provides  step-by-step  instructions  on  how 
to  accomplish  each  task  and  when  to  initiate  it,  as  well  as  describing  possible  prob- 
lem areas  that  may  be  encountered.  This  guide  supplements  the  N flPS-developcd 
modular  TM  specifications. 


FABLE  3-2.  CONTENT  GENERATION  KEY  PROBLEMS  AND  SOLUTIONS 


Key  Problems 

NTIPS  Solutions 

• Subsystem  - low  data  transformation 
accuracy  and  efficiency 

TM  engineer,  TM  Development  Guide, 

: and  procedural  reforms 

• Engineering/Manufacturing  Data 

Base  - no  maintenance  data;  limited 
accuracy  and  currency 

Add  maintenance  requirements  to  MIL- 
STD-100;  automate  data  base 
development 

• Estimating  - inaccurate  TM  estimates; 
poor  compatibility  with  total  ILS 
package 

■ Coordinate  TM  estimating  with  design 
engineering,  ILS  elements,  and  QA 

• Product  Planning  - vague  TM  book- 
plans;  TM  planning  documents  incom- 
patible with  other  ILS  plans 

Modular  TM  specifications;  coordinated 
development  of  TM  and  ILS  planning 
documents 

• Operational  Planning  - poor  writer/ 
work  package  matching 

Upgrade  writing  staff  capabilities 

• Writing  - ineffective  checks  of  TM 
completeness,  accuracy  and  usability 

Concurrent  performance  of  technical 
review,  TM  acquisitions,  IPRs,  and 
validation 
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3.4  DEVPLOPINC  THE  UEl  AH.EU  TM  DESIGN 


rtie  N'l'IPS  I Vl  design  process  provides  a detailed  T.Vl  bookplan  for  a given  system  that 
IS  customized  to  the  equipment  type,  user  personnel  characteristics,  and  the  operation 
.nui  maintenance  environments. 

Designing  l .Ws  to  support  specific  hardware  acquisitions  is  one  of  the  major 
features  of  the  NTIP  preliminary  system  concept.  The  following  parameters  are 
considered  in  the  Tid  design  effort;  equipment  type,  user  personnel  clmracteri.'^tic'., 
operation  and  maintenance  environments,  task  analysis,  and  the  training/teciinical 
manual  tradeoff. 

Applying  the  detailed  f vl  design  effort  to  a modern  shipboard  radar  system 
would  result  in  the  detailed  I d design  documents  illustrated  in  Figure  3-2.  Such 
a radar  would  be  classified  primarily  as  an  electrical/electronic  equipment  and  in- 
cludes variations  in  environment  (internal/external  workspace,  exposure,  and  haz- 
ard), maintenance  (repair  levels),  personnel  (display  operators  and  computer  oper- 
ators), and  training,  (C-school  and  OJ'l  ). 

I'he  first  step  in  the  T.Vi  product  design  process,  which  takes  place  in  the 
N l lPS  user-data  match  function,  is  matching  the  presentation  methods  and  media 
to  the  user.  Descriptions  of  th.e  equipment  types,  personnel  ratings,  task  actions 
to  be  performed,  and  environments  are  input  to  the  user-data  match  model,  fhe 
model's  output  identifies  the  media  and  types  of  TAl  documents  (i.e.,  handbooks, 
work  caros,  microform,  etc.),  and  presentation  components  (e.g.,  text  with  supporting 
pictorials,  illustrations  with  keyed  procedures,  etc.).  For  example,  corrective  main- 
tenance data  for  the  antenna  and  its  drive  assembly  would  be  contained  in  tmndbooks 
using  a presentation  system  of  diagrams  with  supporting  text  (PVRAGRA.M).  Parts 
lists  for  the  drive  assembly  would  use  microfiche,  and  periodic  maintenance  would 
use  work  cards. 

The  next  step  in  the  development  of  the  TM  product  design  (performed  in 
the  Tivl  specification  function)  is  preparation  of  the  TM  specification  document 
that  will  be  used  in  the  procurement  process.  Individual  specification  modules  are 
selected  from  the  TAl  modular  specification  categories  covering  TM  content,  pres- 
entation techniques,  access,  and  readability.  The  selection  is  based  on  the  results 
of  tile  first-cut  task  identification  and  level  of  repair  provided  by  the  NTIPS  user- 
data  matching,  and  tne  training/technical  manual  tradeoff  (tasks  to  be  emphasized 
in  training  vs.  tasks  to  be  emphasized  in  TMs).  For  example,  the  radar  operator's  man- 
ual would  contain  specific  modules  defining  operational  content,  i.e.,  introduction, 
turn-on/checkout,  and  normal,  emergency,  and  maintenance  modes  of  operation. 

The  resultant  customized  document  specifies  to  the  content  generator  the  number 
and  types  of  T.Ms  to  be  prepared,  their  content  down  to  the  chapter  or  section  level, 
and  the  presentation  techniques,  access  methods,  and  readability  criteria  to  be 
employed. 

fhe  final  step,  occurring  in  the  TM  planning  function  of  the  Content  Gener- 
ation Subsystem,  is  to  develop  the  detailed  T\1  design.  Based  on  the  requirements 
in  the  fiVi  specification  and  detailed  descriptions  of  the  individual  units  of  the  radar 
system,  the  content  generator  develops  the  preliminary  planning  documents  down 
to  the  paragraph  level,  fhe  content  generator's  close  proximity  to  the  hardware 
design  engineering  staff  enables  him  to  obtain  detailed  equipment  information  so 
that  he  can  tailor  the  planning  documents  to  the  specific  hardware  characteristics, 
through  a coordinated  effort  with  other  ILS  elements  (i.e.,  training,  detailed  task 
analysis,  optimum  level  of  repair  analysis,  and  spares  provisioning),  these  documents 
arc  reviewed  for  compatibility  with  the  overall  support  program  planning.  Based 
on  the  review  results,  the  content  generator  prepares  the  final  T.vl  bookplans  (de- 
tailed T.vl  design)  from  which  the  actual  IaIs  will  be  developed. 
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Figure  3-2.  Detailed  TM  Design.  A detailed  bookplan  for  a 
considerations  of  user  personnel  characteristics,  equipment  del 
results  of  the  training/technical  manual  tradeoff  and  the  task 
can  he  developed,  enabling  establishment  of  the  most  effectiw 


Detailed  TM  Design.  A detailed  bookplan  for  a shipboard  radar  system  is  derived  from 
I of  user  personnel  characteristics,  equipment  descriptions,  and  environment.  With  the 
training/technical  manual  tradeoff  and  the  task  analysis,  the  TM  modular  specification 
ped,  enabling  establishment  of  the  most  effective  book  content  and  format  for  the  user. 
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Section  3 - Preliminary  NTIP  System  Concept 


3.5  ESTABLISHING  A RELATIONSHIP  BETWEEN  TMs  AND  TRAINING 


To  insure  the  widest  acceptance  and  utility,  TMs  must  be  developed  as  a joint  effort 
of  NTIPS  and  the  Navy  training  community.  A major  aspect  of  this  coordinated  effort 
would  be  the  conduct  of  Training/Technical  Manual  (T/TM)  tradeoff(s)  for  every  system/ 
equipment  procurement. 

The  specification  of  a Training/NTIPS  interface,  in  the  context  of  a system 
concept,  would  be  premature  at  this  time.  However,  a review  of  the  requirements 
for  such  an  interface  is  appropriate,  and  is  presented  here  for  purposes  of  identifi- 
cation of  problems  and  relevant  considerations. 

Numerous  problems  have  been  encountered  in  attempting  to  utilize  the  TM 
as  a training  aid.  Three  problems  produce  a negative  impact  on  the  training  com- 
munity: (1)  the  overall  lack  of  effective  communication  of  information  via  the  TM 
to  the  user,  (2)  topic  coverage  not  being  commensurate  with  the  requirements  of 
the  training  community,  and  (3)  level  (depth)  of  coverage  within  topic  not  being 
commensurate  with  the  requirements  of  the  training  community.  These  problems 
result  in  TMs  not  being  used  as  training  aids  without  substantial  rewriting,  supple- 
menting and  deleting  of  information  contained  in  the  manuals.  Since  these  "revi- 
sions" to  the  TMs  are  generated  by  individual  instructors  on  an  unofficial  basis,  it 
is  not  difficult  to  visualize  the  consequent  inconsistencies  in  training  and,  of  course 
ultimately,  in  on-the-job  performance. 

The  issue  of  effective  communication  is  addressed,  to  a great  extent,  by 
the  user-data  match  function  (see  Topic  4.1.2)  and  need  not  necessarily  involve  the 
training  community  further.  However,  the  other  two  issues  (i.e.,  2 and  3 above) 
indicate  the  need  for  increased  involvement  of  the  training  community  in  the  de- 
velopment of  requirements  for  TMs.  This  would  insure  the  development  of  TMs 
that  are  compatible  with  the  requirements  of  not  only  the  experienced  user  in  the 
field,  but  also,  just  as  important,  serve  the  needs  of  the  novice  during  training. 

In  the  past,  TMs  have  been  developed  that  contain  either  much  more  or  much  less 
information  than  a competent  technician  normally  requires  to  do  his  job.  This  was 
the  result  of  past  attempts  to  produce  technical  manuals  that  would  serve  dual  pur- 
poses - job-oriented  manual  and  training  textbook.  However,  in  the  absence  of  defi- 
nite methods  and  guidelines  for  preparing  the  two  kinds  of  information,  this  cannot 
be  a viable  approach.  As  indicated  by  the  NTIPP  Fleet  Survey  of  Technical  Manual 
Users  the  result  can  be  a technical  manual  that  is  really  not  suited  either  to  training 
or  job  application. 

While  the  importance  of  establishing  and  maintaining  a Training/NTIPS  in- 
teraction is  readily  apparent,  there  are  certain  preliminary  requirements  for  such 
a relationship  to  be  productive.  One  such  issue  that  requires  early  resolution  is 
the  clear  definition  of  the  exact  purpose  of  the  technical  manual.  That  is,  is  the 
TM  to  be  constructed  primarily  for  training  purposes  or  for  job-performance  pur- 
poses, or  carefully  optimized  for  both  applications. 

An  approach  that  appears  to  have  considerable  merit  is  to  optimize  the 
technical  manual  for  on-the-job  use  by  a trained  technician/operator  (e.g.,  U.S. 

Army  ITDT).  In  this  approach,  all  "training"  material  is  contained  in  a separate 
document  which  is  used  during  training  or  for  reference  by  the  operator/technician. 
The  TM,  then,  is  not  intended  to  "train"  anyone  to  do  anything.  Rather,  it  is  to  be 
used  by  an  individual  in  much  the  same  way  that  a checklist  would  be  used:  the 
content  is  behavior  directing,  but  assumes  a user  who  has  been  trained  to  exhibit 
the  expected  behavior. 

Guidelines  for  the  T/TM  Tradeoff  - Once  the  training/job  purposes  of  the 
TM  have  been  determined,  guidelines  can  be  developed  for  the  assignment  of 
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information  coverage  to  either  training  or  the  technical  manual.  Table  3-3  pro- 
vides an  indication  of  the  diversity  of  task  types  that  will  have  to  be  accommodated 
by  the  T/Tivi  tradeoff,  and  how  these  tasks  might  be  assigned  to  coverage  in  training, 
the  TM,  or  both.  This  table  is  not  the  result  of  an  exhaustive  study  and  does  not 
represent  the  extent  of  the  guideline  needed  to  perform  the  T/TM  tradeoff. 

The  subsequent  application  of  the  necessary  guidelines  (for  every  system/ 
equipment  procurement)  will  constitute  the  T/TM  tradeoff.  This  tradeoff  will  de- 
termine the  quantity  and  type  of  information  contained  in  the  TM  versus  the  quantity 
and  type  of  information  that  should  be  acquired  by  the  operator/maintenance  tech- 
nician during  his  training. 


TABLE  3-3.  MATRIX  SHOWING  POSSIBLE  ASSIGNMENT  OF  TASK-RELATED 
FACTORS  OF  TRAINING/TECHNICAL  MANUAL  CATEGORIES 


Factors  Relating  to  Tasks 

Now  Covered 

Primarily 
in  Training 

Primarily 
in  TM 

Both  in 
Training 
and  in  TM 

Tasks  that  are  difficult  to  learn  on  the  job 

X 

Tasks  that  are  most  easily  demonstrated 

X 

Tasks/skills  that  require  extensive  prac- 
tice or  psyehomotor  skills 

X 

- -"1 

Tasks  critical  to  job/overall  mission 

X i 

Tasks  involving  complex  behavioral 
responses 

X 

Tasks  involving  readings  and  measurements 
referred  to  in  tables,  diagrams,  and  charts 

! 

X 

Tasks  with  branching  step  structures 

1 

X 

Tasks  performed  frequently  on  the  job 

X 

Tasks  that  can  be  mastered  via  low-cost 
training 

X 

Rarely  performed  but  critical  tasks 

1 

1 

X 

Tasks  that  are  hard  to  conceptualize  with- 
out visual  reference 

j 

i 

X 

Tasks  that  require  access  to  system/ 
subsystem  data  for  completion 

X 

Tasks  where  speed  of  response  is  critical 

X 

Tasks  where  there  may  be  severe  opera- 
tional penalties  for  error 

X 

Section  3 - Preliminary  NTIP  System  Concept 


3.5  ESTABLISHING  A RELATIONSHIP  BETWEEN  TMs  AND  TRAINING  (Continued) 


Common  sense  suggests  that  certain  tasks  could  be  quickly  excluded  from 
a requirement  for  technical  documentation.  For  example:  (1)  where  the  task  has 
been  previously  learned,  no  further  training  or  documentation  is  needed  (such  as 
use  of  common  test  equipment  or  tools);  (2)  documentation  need  not  be  provided 
where  the  task  will  be  mastered  (learned)  during  training  (e.g.,  a basic  skill,  such 
as  safety  wiring);  or  (3)  where  the  task  requires  neither  training  nor  documentation 
because  it  can  be  quickly  and  accurately  learned  on  the  job  (such  as  a simple  inspec- 
tion procedure).  Similarly,  there  will  be  certain  instances,  such  as  parts  lists,  where 
It  is  self-evident  that  particular  information  will  be  provided  to  the  user  via  the  Tlvl. 
However,  other  types  of  information  (e.g.,  scheduled  maintenance  task  descriptions) 
will  be  found  to  be  not  so  readily  consigned  to  exclusive  coverage  during  training  oi 
in  the  technical  documentation,  nor  can  this  int'ormatioii  be  excluded  from  presenta- 
tion altogetlier.  I his  is  the  type  of  information  that  will  necessari.y  be  covered  both 
in  training  and  in  the  TiVi,  and  will  present  the  most  difficult  T/TM  t"ddeoff  problems 
in  terms  of  requiring  the  careful  application  of  T/ fiU  tradeoff  strateg  ;. 

Task  Analyses  - A factor  that  is  crucial  to  the  successful  bal,  e between 
training  and  TMs  is  the  depth  and  accuracy  of  the  task  analysis  performed  during 
each  procurement.  It  is  the  results  of  the  task  analysis  that  ultimately  determines 
the  pool  of  items  that  will  be  traded-off.  Because  of  the  importance  of  the  task 
analysis  to  the  quality  of  the  final  product,  NTIPS  and  the  Navy  training  community 
should  jointly  provide  specifications  concerning  how  the  analysis  should  be  conducted 
and  what  information  (data  elements)  is  to  be  generated.  In  addition,  a determina- 
tion must  be  made  regarding  how  to  use  the  data  obtained  from  the  three-year  task 
inventory  program  carried  out  by  the  Navy  Occupational  Task  Analysis  Project. 

Much  work  has  already  been  done  in  this  area,  notably  by  Joyce,  et  all, 
and  by  Chenzoff2.  Both  these  authors  have  described  ways  of  gathering  data  for 
fully  proceduralized  job  performance  aids  (JPA).  Although  the  level  of  detail  and 
purpose  of  JPAs  may  be  different  from  the  kind  of  TMs  needed  to  maintain  a com- 
plex system,  Chenzoff  and  Joyce  discuss  a logical  scheme  for  conducting  detailed 
task  analyses.  It  appears  feasible  to  develop  guidelines  for  assigning  data  items 
based  on  tasks  to  either  training  or  to  TMs,  or  to  both.  But,  before  this  could  be 
done,  it  would  require  that  the  Chief  of  Naval  Education  and  Training  develop  pre- 
cise definitions  of  the  roles  and  objectives  of  the  training  community  in  developing 
TMs  suitable  for  training  applications.  A close  liaison  would  be  required  with 
schools  serving  various  technical  ratings,  since  their  training  patterns  differ  some- 
what according  to  the  complexity  and  type  of  equipment  covered  by  the  training. 

Career  Path  Considerations  - Training  and  TMs  must  be  developed  with 
due  consideration  for  the  user's  career  pattern.  Some  commands  are  reluctant  to 
expend  training  funds  on  rates  having  a limited  career  future  in  the  Navy.  In  these 
instances  it  may  be  more  cost  effective  in  the  long  run  to  develop  TMs  which  con- 
tain a high  proportion  of  training  material.  Maintenance  performance  and  effective- 
ness, as  acquired  through  training  versus  the  TM,  must  be  considered  in  terms  of 
the  relative  return  on  dollar  investment  when  judging  the  balance  between  training 
and  TM  content. 

1.  Joyce,  R.P.,  Chenzoff,  A.P.,  and  Mulligan,  J.F.,  Fully  Proceduralized  Job  Per- 
formance Aids  - Handbook  for  JPA  Developers,  Applied  Science  Associates, 
Valencia,  PA,  August  1973. 

2.  Chenzoff,  A.P.,  Aeronautical  Requirements  - Integrated  Development  of 
Training/Performance-Aid  Requirements  for  Naval  Air  Maintenance  Personnel, 
Applied  Science  Associates,  Valencia,  PA,  August  1973. 
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The  pattern  of  training  and  career  development  followed  by  the  various 
TM  users  is  thus  another  important  consideration  in  establishing  guidelines  for  the 
T/T\l  tradeoff.  Those  individuals  who  follow  an  on-the-job  training  path  typically 
pick  up  their  required  information  on  a trial-and-error  basis,  supplemented  by  gen- 
eral information  from  the  achievement-in-rate  manuals.  These  individuals  will  nec- 
essarily rely  upon  technical  documentation  to  a relatively  great  extent,  and  thus 
a relatively  high  proportion  of  "training"  material  must  be  available  to  them  via 
the  TM.  By  way  of  contrast,  those  persons  who  follow  the  comparatively  academic 
career  path  (i.e.,  from  recruit  training  to  "A"  school,  to  "C"  school,  to  operational 
assignment)  seem  to  have  relatively  less  requirement  for  training  information  in 
the  TMs  tliey  use.  That  is,  a higher  proportion  of  this  information  will  be  presented 
during  formal  training  and  need  not  be  duplicated  in  the  TM. 

The  NTIPS  requirements  for  each  path  are  different.  Analysis  of  the  tasks 
carried  out  at  different  stages  of  a career  must  be  done  in  the  context  of  informa- 
tion needs  for  training.  To  date  this  type  of  analysis  has  not  been  done.  The  train- 
ing community  is,  of  course,  vitally  interested  in  improving  the  quality  of  technical 
information  and  TMs  used  in  "C"  school  courses  so  that  the  difficult  task  of  training 
on  complex  systems  is  more  easily  accomplished.  If  standard  technical  information 
supplied  by  equipment  contractors  were  better  suited  to  training  needs,  it  would 
be  a major  accomplishment  in  cost/performance  effectiveness. 

Finally,  the  Navy's  Training  Analysis  and  Evaluation  Group  (TAEG)  has  pub- 
lished a Needs  Assessment^  which  points  to  issues  that  TAEG  feels  address  Training 
Command  interests  in  NTIPP.  Some  of  these  issues,  and  their  respective  recom- 
mendations, require  a clear  and  fairly  precise  determination  of  the  relationship 
between  the  NTIP  System  and  the  Navy  training  community.  This  determination 
has  not  been  made  to  date,  but  it  is  anticipated  that  during  Phase  II  of  NTIPP  a 
working  liaison  will  be  established  between  the  NTIPP  staff  and  Navy  training  per- 
sonnel. This  liaison  would  provide  a clearer  perspective  on  the  relationship  between 
training  and  the  TM  that  would,  consequently,  enhance  the  development  of  a T/TM. 


3.  Braby,  R.,  Training  Requirements  for  the  Naval  Technical  Information  Presen- 
tation Program:  A Needs  Assessment  (Technical  Memorandum  77-3),  U.S.  Navy 
Training  Analysis  and  Evaluation  Group,  Orlando,  FL,  April  1977. 
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3.6  TECHNICAL  APPROACH  TO  PUBLISHING  SUBSYSTEM 

/ 

1 o met  the  enormous  initial  publishing  and  updating  requirements  of  tne  future,  a fully 
automated  publishing  operation  is  needed.  Thus,  a digital  data  base  and  a digital  pro- 
duction approach  are  proposed  as  a Navy  internal  capability.  

Three  to  four  million  TM  pages  enter  the  Navy’s  TM  inventory  each  year, 
most  of  them  generated  and  published  by  equipment  contractors.  Eight  hundred 
thousand  pages  of  updates  of  in-production  equipment  TMs  are  also  processed  each 
year,  again  mostly  by  equipment  contractors.  Even  updates  on  out-of-production 
equipment  TMs  are  largely  contracted  by  the  Navy  to  publications  services. 

Under  the  concept  envisioned,  the  Navy  would  develop  an  internal  digital 
production  capability  by  the  early  1980s  to  perform  all  TM  updates  for  out-of- 
production equipment,  and  also,  if  needed,  for  in-production  equipment  TMs.  In 
the  1980s,  the  Navy  would  also  perform  all  digital  production  of  new  technical  in- 
formation generated  by  Navy  content  generators  and  the  processing  into  TM  mas- 
ters of  all  technical  information  output  of  equipment  contractors.  Ultimately,  the 
majority  of  TM  pages  would  be  handled  by  Navy  publishing  activities  to  perform 
the  digital  production,  preparation  of  masters  in  the  prescribed  medium,  replication 
as  needed,  and  delivery  of  the  TMs  to  the  user. 

Essentially,  the  preliminary  concept  for  publishing  calls  for  a digital  produc- 
tion function  to  enter  digital  magnetic  tape  output  from  equipment  contractors 
and  a full  range  of  batch  and  interactive  text  and  graphic  entry  devices  to  handle 
Navy  internal  content  generation  and  TM  updates.  The  digital  production  function 
provides  the  necessary  computer  processing  capability  and  associated  working  stor- 
age. In  addition,  the  Publishing  Subsystem  has  the  means  to  master  the  Tm  pages 
being  processed  for  replication  into  a specified  medium.  Although  printed  paper 
book's  and  microforms  arc  the  preliminary  concept  media  choices,  the  caoability 
is  provided  to  transition  into  one  or  more  other  candidate  media  such  as  video 
discs  or  digit.il  holograms. 

Although  the  Navy  has  some  publishing  capability  utilizing  automated  equip- 
ment (e.g.,  ADPREPS  and  TRUMP),  what  exists  and  what  has  been  learned  of  plans 
for  enhancements  falls  short  of  providing  the  capability  described  above  for  digital 
processing  and  mastering.  Presently,  no  internal  capability  exists  for  replication 
of  printed  paper  books  or  microforms  since  it  is  predominately  contracted  by  NPPSO 
to  printing  contractors.  However,  whether  this  is  the  approach  to  be  taken  for  new 
media  still  remains  to  be  determined. 

To  achieve  the  full  capability  needed  to  publish  the  well  over  three  million 
pages  each  year  is  not  without  problems.  Several  of  these  deal  with  developing 
and  standardizing  the  digital  processes  and  products  that  are  needed,  such  as  cre- 
ating a digital  TM  data  base  (to  become  the  working  archive),  being  able  to  accept 
input  from  various  equipment  contractors,  and  providing  the  same  digital  produc- 
tion capability  in  different  publishing  operations.  Other  problems  relate  to  the  transi- 
tion to  new  media  and  the  use  of  contractors  to  perform  publishing  operations. 

At  the  time  a system/equipment  transitions  from  in-production  to  out-of- 
production status,  the  TM  data  base  (master  copy  of  TM  pages)  is  often  either  in- 
complete or  in  different  output  media  forms  (negatives,  reproducibles,  printed  books), 
and  it  may  be  stored  by  the  contractor,  NPFC,  or  possibly  at  one  of  the  CFAs,  or 
scattered  among  all  three.  This  situation  imposes  an  added  expense  on  the  Navy 
internal  publications  activity  in  processing  subsequent  updates.  Some  form  of  master 
copy  must  be  created  (if  none  exists)  in  order  to  process  TM  changes.  Therefore, 
the  means  will  be  provided  in  publishing  activities  to  process  all  cu'-rent  TM  data 
into  a aigital  form  for  storage  in  a controlled  working  archive.  Control  of  the  input 
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to  the  data  base  is  assigned  to  the  Publishing  Subsystem  since  the  capabilities  for 
entry  and  processing  reside  there. 

The  implementation  of  the  above  concept  must  consider  that  there  are 
many  different  styles  of  outputs  from  contractors.  This  would  impose  a difficult 
task  on  the  Navy  activity  inputting  the  T1  to  be  processed  or  converted  to  a TM 
data  base.  That  activity  would  have  to  be  able  to  respond  to  such  different  inputs 
as  paper  tape;  magnetic  tape  reels,  cassettes,  cartridges  or  discs;  manuscript  copy; 
original  drawings;  photo  copies  of  drawings;  and  final  repro  copy.  Navy-wide  stan- 
dards for  both  contractors  and  Navy  input  to  the  TM  data  base  will  be  developed. 

A combination  of  digital  magnetic  tape,  OCR,  and  graphic  scanning  (similar  to  that 
specified  by  the  current  NAVAIR  "input  control  document"  being  reviewed  for  com- 
ments by  NAVAIR  contractors)^  could  realistically  limit  the  forms  of  data  to  be 
input  to  publishing  and,  subsequently,  the  TM  data  base.  However,  a single  form 
of  acceptable  equipment  contractor  output  is  recommended.  That  form  is  magnetic 
digital  tape. 

Additionally,  the  implementation  must  provide  consistent  and  standard 
Navy  publishing  activities,  which  is  not  presently  the  situation.  Two  different 
publishing  system  approaches  have  been  taken  in  the  TRUMP  and  ADPREPS  develop- 
ments by  NAVAIR  and  NAVSEA,  while  NAVELEX  has  no  internal  publishing  capa- 
bility. Internal  publishing  systems  would  be  structured  to  accommodate  the  above 
input  standards  and  handle  the  forecasted  workloads.  Further,  Navy-wide  automated 
publishing  systems  (all  major  acquisition  activities)  that  are  at  least  Navy  compat- 
ible (perhaps  DoD  compatible)  would  result. 


TABLE  3-4.  NTIPS  PUBLISHING  APPROACH 

Problem 

Solution 

Incomplete  or  nonexistent  Navy  data 
base  of  TM  masters  for  either  iti- 
production  or  out-of -production  equip- 
ment for  use  by  Navy  for  TM  updates. 

Build  a digital  TM  data  base  and  keep  it 
current  while  equipment  is  in  production 
(using  Publishing  Subsystem  to  accept 
and  process  all  technical  information). 

Diverse  automated  publishing  capabil- 
ity throughout  Navy,  but  too  limited 
to  support  projected  TM  publishing 
needs. 

Provide  standardized  automated  digital 
publishing  systems  (using  latest  tech- 
nology) to  accept  a full  range  of  text 
and  graphic  formats  from  Equipment 
Contractors  and  Navy  publications 
operations. 

^Letter  AIR  04A4;  HLK;  Sg/214,  Review  of  Technical  Review  and  Update  of 
Manuals  and  Publications  (TRUMP)  Input  Requirements,  10  August  1977. 
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3.6  TECHNICAL  APPROACH  TO  PUBLISHING  SUBSYSTEMS  (Continued) 


Although  text  automation  has  been  highly  developed,  graphics  automation 
has  lagged.  Current  Navy  system  approaches  to  handling  graphics  is  still  visual/ 
manual.  Digital  graphic  processing  is  expected  to  continually  progress  into  the 
I980's,  making  digital  graphics  us  cost-effective  as  digital  text  processing.  In  this 
case,  the  Navy  should  develop  mechanisms  to  continually  assess  graphic  automation 
development,  and  provide  for  graphics  automation  in  the  NTIP  System  design. 

Printed  paper  books  and  microforms  are  the  current  user  media  and  will 
be  employed  for  several  more  years.  It  will  probably  be  at  least  four  or  five  years 
before  any  candidate  media  (video  discs,  holograms,  direct  digital,  etc.)  can  be  de- 
veloped sufficiently  to  be  implemented  in  place  of  paper  and/or  microforms.  When 
a change  is  contemplated,  the  impact  on  the  investment  (facilities  and  equipment), 
the  personnel,  and  the  manner  of  doing  business  will  have  to  be  evaluated.  The 
latter  refers  to  the  almost  total  dependence  on  contractors  for  replication,  which 
could  change  with  different  media.  NTIPS  needs  to  be  reactive  to  the  different 
media  possibilities  and  to  the  equipment/methods  required  to  process,  replicate, 
and  supply  each  to  the  users. 

Finally,  how  much  internal  publishing  capability  is  acceptable  must  be  de- 
termined in  light  of  the  interpretations  made  of  the  Office  of  Management  and 
Budget  and  Congressional  Joint  Committee  on  Printing  policies.  For  example,  all 
TM  printing  is  contracted,  and  TRUMP  has  been  forced  into  a Government-owned/ 
contractor-operated  (GOCO)  mode  of  operation.  Continual  assessment  of  publish- 
ing requirements  pertaining  to  this  problem  area  (particularly  the  changes  that 
could  result  from  media  decisions)  are  needed  and  planned. 


I 

I 
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TABLE  3-4.  NTIPS  PUBLISHING  APPROACH  (Continued) 


Problem 

Solution 

Automated  graphics  processing  is 
lagging  text  processing  in  both  extent 
of  capability  and  cost  (investment  and 
operation). 

Anticipate  technology  developments 
and  a decline  in  costs  will  permit 
full  autoinated  graphics  implemen- 
tation in  early  1980's. 

Wide  variety  of  text  and  graphics  pro- 
cessing methods,  technical  information 
formats,  and  standards  for  replication 
and  other  publishing  processes  and 
products. 

Develop  Navywide  standards  for  both 
contractors  and  Navy  publishing  activ- 
ities, particularly  for  the  interfaces  of 
processes  used  and  product  formats. 

Current  printed  paper  books  and  micro- 
forms may  be  replaced  by  new  media 
(e.g.,  video  discs  or  holograms). 

Although  not  imminent,  the  mastering 
and  replication  function,  must  be  struc- 
tured to  make  changeover  to  handle  new 
media. 

Present  TM  printing,  microform  dupli- 
cation, and  some  digital  production 
(e.g.,  TRUMP)  are  or  are  about  to  be 
performed  by  Contractors  (0MB  and 

JCP  policy  interpretation). 

Role  of  Contractors  to  be  contin- 
ually assessed  during  design  phase. 
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3.7  CONSIDERATIONS  IN  SELECTING  TM  MEDIA 


The  current  primary  media  are  printed  paper  books  and  microforms,  but  several  other 
user  media  are  viable  candidates  for  the  NTIP  System.  Initial  considerations  for  selec- 
tion of  other  media  must  account  for  various  media  transforms  during  processing. 

The  preliminary  system  concept  has  been  developed  to  accommodate,  as 
primary  media,  the  currently  used  printed  paper  books  (delivered  to  the  user)  and 
cartridge  and  fiel'.e  inicrofe."ms.  N'FIPS  is  functionally  structured  to  also  accom- 
modate other  media  considered  as  potential  candidates  for  the  1980-85  time  frame. 
Roth  the  primary  and  potential  media  are  described  below  and  shown  in  Table 
3-5.  The  following  two  currently  used  media  were  selected  for  the  preliminary 
system  concept  since,  even  if  a new  medium  is  selected,  these  two  will  be  used  for 
at  least  five  more  years,  and  any  new  medium  would  have  to  transition  from  them. 

Printed  Paper  Book  - This  is  the  familiar  conventional  printed  pages  of  text 
and  graphics  collated  and  bound  together  as  a book.  The  most  common  size 
is  8-1/2  by  11  inches,  but  they  range  in  size  from  about  4 by  6 inches  for 
pocket  books  to  the  15  by  30  inches  used  for  BAM  AG  AT  and  SIM  M TMs. 
Color  can  be  used,  again  SIMM  is  an  example,  but  most  paper  books  are 
black  and  white  printing.  Printed  paper  books  require  no  special  equipment 
to  be  employed  by  the  user. 

Microforms  - These  are  greatly  reduced  photographic  copies  of  pages  of 
I text  and  graphics.  There  are  several  forms  in  use,  but  the  one  that  has 

1 achieved  widest  acceptance  to  date  is  the  microfiche.  This  is  a piece  of 

E film,  measuring  105  by  148  mm,  that  has  from  98  to  several  hundred  pages 

1 per  fiche.  Other  forms  are  roll  film  and  aperture  cards.  Microforms  re- 

! quire  the  user  to  have  access  to  a viewer  or  viewer/printer.  Microforms 

I have  black  and  white  images.  Color  is  possible,  but  seldom  used. 

I The  following  are  the  three  candidate  media  that  are  most  likely  to  replace 

f the  current  media  in  the  1980s.  All  are  in  early  stages  of  development  and  will 

I need  to  be  tested  in  the  user  environment. 

; Video  Disc  - This  is  either  a video  or  digital  representation  of  pages  of  text 

and  graphics.  Several  thousand  pages  are  recorded  on  a hard  12-inch  disc 
(that  looks  like  a phonograph  record)  or  a soft  (floppy),  transparent  12-inch 
disc.  To  be  used,  video  discs  require  a converter,  viewer,  and  (as  needed) 
a replication  device.  Video  discs  are  the  only  medium  in  the  group  that 
can  provide  sound  and  motion  portrayals  as  well  as  the  static  picture  of 
a page.  Video  discs  provide  color  images  using  video  and  black  and  white 
images  using  digital. 

Digital  Hologram  - This  is  also  a digital  representation  of  pages  of  text 
and  graphics.  Several  thousand  pages  are  contained  on  one  piece  of  film 
measuring  105  x 148  millimeters.  To  be  used,  digital  holograms  need  a con- 
verter, viewer,  and  (as  needed)  a replication  device.  One  form  of  hologram 
combines  microform  images  with  digital  data  on  the  same  film,  providing 
I additional  versatility  in  field  applications.  Images  are  black  and  white. 

Direct  Digital  - The  direct  transmission  of  digital  representations  of  TM 
pages  to  the  user  from  a centralized  TM  data  base  is  the  final  candidate. 

To  use  the  direct  digital  medium,  a receiver,  converter,  viewer,  and  (as 
needed)  a replication  device  are  required.  Images  are  black  and  white. 


I 
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TABLE  3-5.  IMPLICATIONS  OF  MEDIA  SELECTION 


User 

Devices 

Storage 

Media 

Processing 

Delivery 

User 

Processing 

Preliminary  System 
Concept 

• Printed  Paper 

Books 

■ ■ 

Digital 

Printed  paper 
books 

None 

Paper  books 

Digital  TM 
data  bank 

• Microforms 

Digital 

Microform 

Viewer, 

Printer 

Microform 

Digital  TM 
data  bank 

Candidate  Media 

• Video  Disc 
(Video) 

Audio/visual 

(video 

methods) 

Video  disc 

Converter, 

viewer 

\ ideo  disc 

Video 

• Video  Disc 
(Digital) 

Digital 

Video  disc 
(digital) 

Converter, 

viewer, 

printer 

Video  disc 

Digital  TM 
data  bank 

• Digital  Holograms 

Digital 

Hologram  film 

Converter, 

viewer, 

printer 

Hologram 

film 

Digital  TM 
data  bank 

• Direct  Digital 

Digital 

Data  comm, 
signal 

Receiver, 

converter, 

viewer, 

printer 

Digital 

memory 

Digital  TM 
data  bank 

Other  Potential  Media 

• Digital  Memory 
(Deliverable) 

Digital 

Bubble  or  simi- 
lar type  mem- 
ory device 

Converter, 

viewer, 

printer 

Digital 

memory 

Digital  TM 
data  bank 

• Digital  Tape 

Digital 

Tape,  cartridge, 
etc. 

Converter, 

viewer, 

printer 

Digital  tape 

Digital  TM 
data  bank 

• Video  Tape 

Audio/visual 

(video 

methods) 

Tape,  cartridge 

Converter, 

viewer 

Video  tape 

Video 

masters 

• Other  Audio/Visual 

Audio/visual 

(various 

methods) 

Motion  pictures, 
film  strips,  audio 
tape,  etc. 

Converter, 

viewer 

Audio/video 

media 

Audio/video 

masters 
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As  wilti  the  microform  medium,  there  is  a requirement  to  provide  a second- 
ary medium  for  use  where  the  viewing  devices  cannot  be  taken.  This  medium  would 
be  paper  copies  of  pages  of  text  and  graphics  prepared  on  the  replication  devices 
used  in  conjunction  with  the  viewers.  One  page  of  text  or  one  page  unit  of  art  would 
be  reproduced  on  paper  approximately  8-1/2  x 1 1 inches  and  only  black  and  white 
images  would  be  provided. 

There  are  other  potential  media  shown  in  Table  3-5.  These  include  digital 
tape,  video  tape  or  other  audio/visual  media,  and  a deliverable  digital  memory. 
Although  not  considered  to  be  leading  candidates  at  this  ti  ne,  they  all  need  to  be 
continually  assessed.  Digital  tape  and  the  audio/visual  devices  are  the  familiar  con- 
ventional media  now  in  use.  The  only  unique  medium  would  be  a deliverable  digital 
memory  such  as  the  newly  developed  magnetic  bubble  memories.  These  are  mass 
memory  devices  that  would  in  the  future  hold  all  of  the  TMs  on  a ship  or  at  a NARF 
in  a memory  that  would  fit  into  a shoe  box. 

All  media  being  considered  (see  Table  3-5)  are  either  dynamic  (that  is,  use 
sound  and/or  motion)  or  static  and  can  be  used  in  either  interactive  and  passive 
modes.  Of  the  media  described,  only  the  video  disc  has  capability  for  both  static 
and  dynamic  action  portrayals.  Video  tape  and  motion  picture  film  can  also  provide 
action,  such  as  a technician  actually  performing  a disassembly  accompanied  by  an 
audio  description  of  what  is  taking  place.  An  interactive  application  of  media  is 
the  user  device  that  provides  an  interaction  between  the  user  and  the  device.  The 
device  leads  the  user  through  a man/maehine  dialog  of  a troubleshooting  routine 
or  a training  exercise.  A visual  display/keyboard  terminal  with  processor  and  asso- 
ciated storage  is  the  usual  configuration  for  such  an  interactive  device.  The  medium 
provided  the  user  can  be  all  digital  (i.e.,  floppy  disc)  or  a combination  of  digital 
and  visual  (i.e.,  video  disc).  Both  are  used  in  current  interactive  devices.  The  video 
disc  systems  can  provide  the  added  dynamics  of  sound  and  motion  to  maintenance 
routines  or  training  exercises. 

Most  subsystems  of  NTIPS  are  affected  by  the  medium/media  utilized  for 
delivery  of  the  TM  to  the  user.  The  TM  specification  function  must  develop  the 
specifications  and  standards  for  TMs  prepared  for  a specific  medium,  particularly 
the  mechanical  specifications  for  the  medium  itself.  The  content  generators  must 
respond  differently  if  a medium  is  dynamic  rather  than  static.  For  example,  if  a 
video  disc  was  specified  with  a sound  and  action  sequence  showing  a maintenance 
technician  performing  a part  disassembly,  the  content  generator  would  prepare  a 
script,  not  a page  for  a book.  The  choice  of  medium  has  a significant  impact  on 
the  publishing  activities  since  technical  information  can  change  from  one  medium 
to  another  as  it  is  processed  through  publishing  operations  and  ultimately  delivered. 
There  are  several  different  forms  (or  media)  that  technical  information  takes  during 
the  automated  publishing  cycle.  First,  in  the  preliminary  system  concept  it  is  cap- 
tured and  processed  by  the  publishing  functions  in  digital  form.  It  is  then  output, 
mastered,  and  replicated  as  a TM  in  a different  form  for  delivery  to  the  user.  That 
form  would  be  any  one  of  the  media  described  above  and  shown  in  Table  3-5.  When 
delivered,  in  order  for  a medium  to  be  used,  there  must  be  one  or  more  devices  which 
create  a final  use  medium.  For  example,  a viewer  or  viewer-printer  is  needed  for 
microforms.  This  is  true  for  all  media  but  printed  paper.  Use  of  media  in  the  user 
community  is  the  subject  of  the  following  topic. 

Finally,  there  is  a need  for  storage.  There  are  two  basic  storage  require- 
ments: that  related  to  the  processing  of  technical  information  into  TMs,  and  that 
related  to  TM  use  in  the  user  environment.  Storage  of  media  takes  on  importance 
when  discussed  in  light  of  the  amount  of  TMs  to  be  processed,  delivered,  and  used. 
With  3 to  4 million  pages  to  be  processed  each  year,  many  times  that  in  delivery 
media  (replicated  copies  of  the  output),  and  often  over  a hundred  thousand  pages 
at  any  one  user  location  (on  a ship  or  at  a NARF),  storage  becomes  a significant 
factor  in  the  design  process. 
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3.8  USE  OF  MEDIA  IN  THE  USER  COMMUNITY 


Microforms  and  printed  paper  books  are  TM  media  that  are  used  quite  differently  in 
the  user  environment.  Microforms,  and  other  similar  candidate  media  require  user 
reproduction  and  viewing  devices,  which  appear  to  be  negative  aspects  of  the  media. 

The  primary  consideration  in  the  analysis  of  a medium  is  effectiveness  in 
the  user  environment.  The  media  designated  for  the  preliminary  system  concept, 
printed  paper  books  and  microforms,  are  presently  in  use  and  have  been  accepted, 
to  some  degree,  as  effective  in  the  user  environment.  Other  candidate  media  still 
need  to  be  so  evaluated. 

All  future  candidate  media  require  one  or  more  devices  to  make  them  fully 
useful  in  the  field.  Devices  are  needed  to  provide  (1)  conversion  of  the  media  for 
viewing,  (2)  the  actual  viewing,  and  (3)  replication  of  the  viewed  image,  if  desired. 

In  addition,  all  media  also  require  storage  and  containers  (or  devices)  for  storage. 
Pertinent  considerations  for  use  of  media  in  the  user  community  are  provided  in 
Table  3-6  and  discussed  below. 

For  all  but  printed  paper  books,  the  user  must  view  the  information  (pro- 
vided by  some  media)  on  a viewing  device.  The  process  begins  with  the  user  looking 
at  an  index  or  table  of  contents  to  determine  where  (in  the  media)  the  needed  in- 
formation can  be  found.  The  media  must  then  be  searched  until  the  information 
is  located.  When  located,  it  is  presented  on  a viewer  so  that  it  can  be  read  by  the 
user.  This  satisfies  the  initial  need  for  information,  but  there  may  be  a subsequent 
need  to  take  the  information  to  another  location.  If  a replication  device  is  asso- 
ciated with  the  viewing  device,  such  as  the  microform  viewer/printer,  then  the  user 
can  make  a paper  copy  of  the  needed  information  that  can  be  taken  and  used  where 
a viewer  cannot  be  taken. 

Viewing  of  these  media,  therefore,  is  the  primary  need.  Replicating  the 
viewed  image  is  secondary  because  it  may  or  may  not  be  required.  An  example 
that  does  not  require  replication  might  be  basic  reference  data  such  as  parts  lists. 

If  paper  copies  cannot  be  made,  the  capability  to  have  or  be  able  to  carry  the  viewer 
to  where  it  is  to  be  used  is  a considered  alternative.  This  satisfies  the  requirement 
to  support  the  often  expressed  user's  need  for  TM  information  that  can  be  carried 
to  and  used  in  environmentally  difficult  work  areas,  such  as  the  remote  areas  of 
a ship  or  the  tail  section  of  an  aircraft.  Current  technology  microform  viewer/ 
printers  presently  in  use  by  the  Navy  can  provide  the  paper  copies.  The  personal 
portable  microform  viewer  being  developed  under  contract  to  the  NAVSUP  R&D 
activity  is  aimed  at  meeting  this  need  for  a hand-carried  viewer.  Obviously,  printed 
paper  books  do  not  have  these  problems. 

Microforms,  video  discs,  holograms,  and  direct  digital  are  all  media  that 
require  viewing,  and  the  capability  to  "easily"  load  and  locate  the  data  contained 
in  any  of  these  media  would  be  mandatory.  It  should  be  pointed  out  that  there  are 
several  negative  aspects  of  microforms  that  have  been  reported  (including  the  NTIPP 
Fleet  Surveyl),  User  acceptance  has  been  poor  in  the  Navy’s  MIARS  program,  the 
Air  Force  has  abandoned  its  Technical  Order  Microfilm  System  (TOMS)  program, 
and  the  Army  has  diluted  its  microform  program  (see  Task  1 Report  Page  3-236i. 
Since  they  all  require  similar  handling  and  the  same  type  of  devices,  the  problems 
encountered  with  microforms  can  also  be  expected  with  digital  video  discs,  digital 
holograms,  and  the  direct  digital  media. 


1.  Hughes  Aircraft  Company,  Review  Draft,  Special  Report  NTIPP  Fleet  Survey 
of  Technical  Manual  Users,  DTNSRDC.  5 March  1977. 
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As  with  the  microform  medium,  tliere  is  a requirement  to  provide  a second- 
ary medium  for  use  where  the  viewing  devices  cannot  be  taken.  This  medium  would 
be  paper  copies  of  pages  of  text  and  graphics  prepared  on  the  replication  devices 
used  in  conjunction  with  the  viewers.  One  page  of  text  or  one  page  unit  of  art  would 
be  reproduced  on  paper  approximately  8-1/2  x 1 1 inches  and  only  black  and  white 
images  would  be  provided. 

There  are  other  potential  media  shown  in  Table  3-5.  These  include  digital 
tape,  video  tape  or  other  audio/visual  media,  and  a deliverable  digital  memory. 
Although  not  considered  to  be  leading  candidates  at  this  time,  they  all  need  to  be 
continually  assessed.  Digital  tape  and  the  audio/visual  devices  are  the  familiar  con- 
ventional media  now  in  use.  The  only  unique  medium  would  be  a deliverable  digital 
memory  such  as  the  newly  developed  magnetic  bubble  memories.  These  are  ma-ss 
memory  devices  that  would  in  the  future  hold  all  of  the  TMs  on  a ship  or  at  a NARF 
in  a memory  that  would  fit  into  a shoe  box. 

All  media  being  considered  (see  Table  3-5)  are  either  dynamic  (that  is,  use 
sound  and/or  motion)  or  static  and  can  be  used  in  either  interactive  and  passive 
modes.  Of  the  media  described,  only  the  video  disc  has  capability  for  both  static 
and  dynamic  action  portrayals.  Video  tape  and  motion  picture  film  can  also  provide 
action,  such  as  a technician  actually  performing  a disassembly  accompanied  by  an 
audio  description  of  what  is  taking  place.  An  interactive  application  of  media  is 
the  user  d<  vice  that  provides  an  interaction  between  the  user  and  the  device.  The 
device  leads  the  user  through  a man/machine  dialog  of  a troubleshooting  routine 
or  a training  exercise.  A visual  display/keyboard  terminal  with  processor  and  asso- 
ciated storage  is  the  usual  configuration  for  such  an  interactive  device.  The  medium 
provided  the  user  can  be  all  digital  (i.e.,  floppy  disc)  or  a combination  of  digital 
and  visual  (i.e.,  video  disc).  Both  are  used  in  current  interactive  devices.  The  video 
disc  systems  can  provide  the  added  dynamics  of  sound  and  motion  to  maintenance 
routines  or  training  exercises. 

Most  subsystems  of  NTIPS  are  affected  by  the  medium/media  utilized  for 
delivery  of  the  TIM  to  the  user.  The  TIM  specification  function  must  develop  the 
specifications  and  standards  for  TMs  prepared  for  a specific  medium,  particularly 
the  mechanical  specifications  for  the  medium  itself.  The  content  generators  must 
respond  differently  if  a medium  is  dynamic  rather  than  static.  For  example,  if  a 
video  disc  was  specified  with  a sound  and  action  sequence  showing  a maintenance 
technician  performing  a part  disassembly,  the  content  generator  would  prepare  a 
script,  not  a page  for  a book.  The  choice  of  medium  has  a significant  impact  on 
the  publishing  activities  since  technical  information  can  change  from  one  medium 
to  another  as  it  is  processed  through  publishing  operations  and  ultimately  delivered. 
There  are  several  different  forms  (or  media)  that  technical  information  takes  during 
the  automated  publishing  cycle.  First,  in  the  preliminary  system  concept  it  is  cap- 
tured and  processed  by  the  publishing  functions  in  digital  form.  It  is  then  output, 
mastered,  and  replicated  as  a TM  in  a different  form  for  delivery  to  the  user.  That 
form  would  be  any  one  of  the  media  described  above  and  shown  in  Table  3-5.  When 
delivered,  in  order  for  a medium  to  be  used,  there  must  be  one  or  more  devices  which 
create  a final  use  medium.  For  example,  a viewer  or  viewer-printer  is  needed  for 
microforms.  This  is  true  for  all  media  but  printed  paper.  Use  of  media  in  the  user 
community  is  the  subject  of  the  following  topic. 

Finally,  there  is  a need  for  storage.  There  are  two  basic  storage  require- 
ments; that  related  to  the  processing  of  technical  information  into  TMs,  and  that 
related  to  TM  use  in  the  user  environment.  Storage  of  media  takes  on  importance 
when  discussed  in  light  of  the  amount  of  TMs  to  be  processed,  delivered,  and  used. 
With  3 to  4 million  pages  to  be  processed  each  year,  many  times  that  in  delivery 
media  (replicated  copies  of  the  output),  and  often  over  a hundred  thousand  pages 
at  any  one  user  location  (on  a ship  or  at  a NARF),  storage  becomes  a significant 
factor  in  the  design  process. 
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3.8  USE  OF  MEDIA  IN  THE  USER  COMMUNITY 


Microforms  and  printed  paper  books  are  TM  media  that  are  used  quite  differently  in 
the  user  environment.  Microforms,  and  other  similar  candidate  media  require  user 
reproduction  and  viewing  devices,  which  appear  to  be  negative  aspects  of  the  media. 

The  primary  consideration  in  the  analysis  of  a medium  is  effectiveness  in 
the  user  environment.  The  media  designated  for  the  preliminary  system  concept, 
printed  paper  books  and  microforms,  are  presently  in  use  and  have  been  accepted, 
to  some  degree,  as  effective  in  the  user  environment.  Other  candidate  media  still 
need  to  be  so  evaluated. 

All  future  candidate  media  require  one  or  more  devices  to  make  them  fully 
useful  in  the  field.  Devices  arc  needed  to  provide  (l)  cotiversion  of  the  media  for 
viewing,  (2)  the  actual  viewing,  and  (3)  replication  of  the  viewed  image,  if  desired. 

In  addition,  all  media  also  require  storage  and  containers  (or  devices)  for  storage. 
Pertinent  considerations  for  use  of  media  in  the  user  community  are  provided  in 
Table  3-6  and  discussed  below. 

For  all  but  printed  paper  books,  the  user  must  view  the  information  (pro- 
vided by  some  media)  on  a viewing  device.  The  process  begins  with  the  user  looking 
at  an  index  or  table  of  contents  to  determine  where  (in  the  media)  the  needed  in- 
formation can  be  found.  The  media  must  then  be  searched  until  the  information 
is  located.  When  located,  it  is  presented  on  a viewer  so  that  it  can  be  read  by  the 
user.  This  satisfies  the  initial  need  for  information,  but  there  may  be  a subsequent 
need  to  take  the  information  to  another  location.  If  a replication  device  is  asso- 
ciated with  the  viewing  device,  such  as  the  microform  viewer/printer,  then  the  user 
can  make  a paper  copy  of  the  needed  information  that  can  be  taken  and  used  where 
a viewer  cannot  be  taken. 

Viewing  of  these  media,  therefore,  is  the  primary  need.  Replicating  the 
viewed  image  is  secondary  because  it  may  or  may  not  be  required.  An  example 
that  does  not  require  replication  might  be  basic  reference  data  such  as  parts  lists. 

If  paper  copies  cannot  be  made,  the  capability  to  have  or  be  able  to  carry  the  viewer 
to  where  it  is  to  be  used  is  a considered  alternative.  This  satisfies  the  requirement 
to  support  the  often  expressed  user’s  need  for  TM  information  that  can  be  carried 
to  and  used  in  environmentally  difficult  work  areas,  such  as  the  remote  areas  of 
a ship  or  the  tail  section  of  an  aircraft.  Current  technology  microform  viewer/ 
printers  presently  in  use  by  the  Navy  can  provide  the  paper  copies.  The  personal 
portable  microform  viewer  being  developed  under  contract  to  the  NAVSUP  R&D 
activity  is  aimed  at  meeting  this  need  for  a hand-carried  viewer.  Obviously,  printed 
paper  books  do  not  have  these  problems. 

Microforms,  video  discs,  holograms,  and  direct  digital  are  all  media  that 
require  viewing,  and  the  capability  to  ’’easily"  load  and  locate  the  data  contained 
in  any  of  these  media  would  be  mandatory.  It  should  be  pointed  out  that  there  are 
several  negative  aspects  of  microforms  that  have  been  reported  (including  the  NTIPP 
Fleet  Survey!).  User  acceptance  has  been  poor  in  the  Navy’s  MIARS  program,  the 
Air  Force  has  abandoned  its  Technical  Order  Microfilm  System  (TOMS)  program, 
and  the  Army  has  diluted  its  microform  program  (see  Task  1 Report  Page  3-236). 
Since  they  all  require  similar  handling  and  the  same  type  of  devices,  the  problems 
encountered  with  microforms  can  also  be  expected  with  digital  video  discs,  digital 
holograms,  and  the  direct  digital  media. 


1.  Hughes  Aircraft  Company,  Review  Draft,  Special  Report  NTIPP  Fleet  Survey 
of  Technical  Manual  Users,  DTNSRDC,  5 March  1977. 
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All  media  have  to  be  stored  by  the  user.  The  physical  media  (paper  books, 
fiche,  cartridges,  discs,  holograms)  must  be  kept  in  some  form  of  container.  Even 
direct  digital  needs  a storage  device  (a  memory).  Several  candidate  media  also 
need  storage  for  the  paper,  chemicals,  or  other  supplies  for  the  replication  devices 
employed.  The  tradeoffs  among  media  must  consider,  along  with  the  usability  cri- 
teria, the  space  needed  for  viewers,  replicators,  converters,  and  storage.  With  con- 
cern for  the  physical  space  required,  the  accessibility  of  stored  TMs  must  be  con- 
sidered. How  the  file  is  structured,  the  library  system,  ease  of  access,  and  speed 
of  retrieval  are  factors  important  to  an  effective  storage  method. 

Except  for  storage,  printed  paper  books  delivered  to  the  user  do  not  need 
the  special  handling  or  equipment  of  other  media.  Since  all  other  media  are  likely 
to  be  reconstituted  as  paper  by  the  user,  any  replacement  media  must  be  carefully 
evaluated  to  verify  its  utility  and  the  cost  effectiveness  of  its  selection.  It  must 
be  kept  in  mind  that  the  real  value  is  in  its  use  in  the  user  community. 


TABLE  3-6.  USABILITY  OF  MEDIA  IN  THE  USER  COMMUNITY 


Media 

Access  to  Data 
in  Medium 

Viewing/ 

Transportability 

Versatility 

Storage 

Printed 

Paper  Books 

Table  of  Con- 
tents, Index  in 
document.  Man- 
ual search. 

Viewed  as  is  - 
Can  be  taken 
anywhere. 

Limited  to  pages  of 
text  and  art  bound 
together  in  volumes. 
Can  be  changed. 

Needs  large  area.  Files 
or  bookcases. 

Microforms 

Table  of  Con- 
tents, Index. 

Can  be 
automated. 

Conventional 
viewer  - Special 
lightweight 
viewer  or  paper 
copy  of  micro- 
forms is  needed. 

Limited  to  pages  of 
text  and  art  pack- 
aged together  in  a 
roll  or  on  a fiche. 
Must  be  replaced 
to  change. 

Needs  small  containers 
for  microforms.  Needs 
large  area  for  paper  and 
supplies  for  printer  if 
used. 

Video  Disc 
(Video) 

Table  of  Con- 
tents, Index. 

Can  be 
automated. 

Conventional 
Television  - 
Special  light- 
weight viewer 
is  needed. 

Can  display  pages 
of  text  and  art,  or 
a combination  of 
each.  Must  be  re- 
placed to  change. 

[ 

Needs  small  file  for  discs. 

Video  Disc 
(Digital) 

Table  of  Con- 
tents, Index. 
Always 
automated. 

1 CRT  Viewer  - 
Special  light- 
weight viewer 
is  needed. 

! 

' 

Limited  to  pages  of 
text  and  art  pack- 
aged together.  Must 
be  replaced  to 
change. 

Needs  small  file  for  discs. 
Needs  large  area  for 
paper  and  supplies  for 
printer  if  used. 

Digital 

Hologram 

Table  of  Con- 
tents, Index. 
Always 
automated. 

IcRT  Viewer  - 
Special  light- 
weight viewer 
is  needed. 

Limited  to  pages  of 
text  and  art  pack- 
aged together.  Must 
be  replaced  to 
change. 

Needs  small  file  for  holo- 
gram film.  Needs  large 
area  for  paper  and  sup- 
plies for  printer  if  used. 

Direct 

Digital 

1 

Table  of  Con- 
tents, Index. 
Always 
automated. 

CRT  Viewer  - 
Special  light- 
weight viewer 
is  needed.  Con- 
nection to  data 
bank  also 
needed. 

Groups  of  pages  of 
text  and  art  can  be 
modularized  or  data 
can  be  provided  for  | 
mass  storage  de-  : 

vice.  Changes  are 
made  to  data  bank 
or  storage  devices. _j 

Might  need  digital  stor- 
age device.  Needs  large 
area  for  paper  and  sup- 
plies for  printer  if  used. 

3-25 


Section  3 - Preliminary  N TIP  System  Concept 


3.9  TECHNICAL  APPROACH  TO  DISTRIBUTION  SUBSYSTEM 


The  Distribution  Subsystem  features  a centralized  NTIPS  I'.M  resupply  function  and  dual 
archive,  containing  the  digital  TM  data  base  combined  with  a totally  automated 
decentralized  distribution  control  function  . 

Navy  distribution  activity  falls  into  several  functional  areas.  First,  the 
control  elements  for  initial  distribution  of  I'Ms  of  new  equipment  procurements, 
such  as  where  the  equipment  is  to  be  deployed,  TM  numbers,  etc.,  must  be  estab- 
lished. This  same  control  mechanism  also  needs  to  be  extended  for  subsequent 
changes  to  the  equipment  and  resulting  revisions  to  TMs.  Next,  the  physical  delivery 
of  these  basic  TMs  and  updates  must  be  performed.  In  addition,  extra  copies  of 
TMs  and  updates  need  to  be  stored  for  use  as  replacements  when  requested  by  the 
users.  There  is  another  type  of  storage  requirement  for  the  TM  master  copies  to 
be  used  for  subsequent  processing.  All  of  these  functions,  excluding  delivery  of 
new  'I'Ms  and  subsequent  updates,  are  part  of  the  Distribution  Subsystem.  Because 
it  is  operationally  an  adjunct  to  the  replication  function,  the  excluded  delivery 
function  is  assigned  to  the  Publishing  Subsystem. 

Presently,  the  distribution  activity  in  the  Navy  appears  to  oe  performed 
acceptably  since  no  major  complaints  have  been  uncovered  in  NTIPP  research.  How- 
ever, certain  problems  have  been  identified,  some  of  which  appeared  during  develop- 
ment of  the  Initial  Distribution  Control  function  preliminary  concept. 

The  preliminary  concept  is  to  have  three  functions  to  perform  all  distribu- 
tion requirements:  (1)  a decentralized  initial  distribution  control  function  working 
closely  with  the  acquisition  activities  and  using  the  automated  Management  Informa- 
tion System  (MIS)  for  configuration  and  distribution  control  management  to  handle 
the  over  30,000  yearly  procurement  actions,  (2)  a centralized  TM  resupply  function 
to  provide  physical  storage  of  paper  and/or  microform  copies  of  the  over  150,000 
TMs  in  the  Navy's  inventory,  and  (3)  a centralized  dual  archive  function  containing 
a 130-trillion-bit  digital  data  base  as  a working  archive  for  use  in  update  programs 
and  a historical  archive  which  would  initially  contain  over  30,000,000  TM  pages 
and  which  would  increase  by  3 to  4 million  pages  each  year  as  new  TMs  enter  the 
system. 

fhe  Distributiofi  Subsystem  uses  existing  approaches  where  effective  and  in- 
corporates new  approaclies  where  neces.s.iry.  For  example,  the  existing  STEDMIS/ 

Si  EPS  approach  is  effective  for  configuration  management  and  is  used  by  two  of  the 
three  principal  major  acquisition  activities.  It  should  be  retained  and  its  use  consid- 
ered for  the  tiiiro  major  acquisition  activity.  An  example  of  a new  approach  is  the 
digital  data  base  needed  for  the  working  archive.  I'he  large  quantity  of  TM  pages 
to  be  stored  in  digital  lorm  will  require  application  of  mass  memory  devices,  such 
as  t:ie  newer  cliarge-coupled  devices  or  magnetic  bubble  memories. 

The  example  of  the  application  of  STEDMIS/STEPS  pertains  to  the  distribu- 
tion control  function  where  it  addresses  a primary  concern  of  matching  the  TMs 
to  the  hardware  configurations  at  various  user  locations.  Tracking  and  managing 
the  configuration  data,  the  locations  and  addresses,  along  with  the  publications  iden- 
tification, acquiiition  status,  and  general  distribution  requirements  data,  dictates 
the  use  of  coinpi.ter  automation.  STFlDMIS/SfEPS  would  be  adapted  and  supple- 
mented with  programs  to  enable  the  N PIPS  MIS  to  handle  the  initial  distribution 
data  for  all  active  hardwarc/TM  programs,  rhese  programs  represent  over  150,000 
TMs,  each  one  bi’ing  used  in  as  many  as  several  hundred  locations.  Each  TM  could 
also  exist  in  several  different  configurations  to  support  different  models  or  modifica- 
tions of  a particular  piece  of  equipment.  All  this  makes  the  data  file  and  its 
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automation  and  control  a complex  operation.  Since  each  major  acquisition  activity 
would  have  an  initial  distribution  control  function,  there  is  the  added  need  to  insure 
each  location  has  the  same  capability  and  operates  similarly.  One  specific  problem 
that  has  been  identified  by  the  Navy  is  that  the  actual  user  may  not  be  receiving 
the  TM  or  updates  he  needs  although  they  have  been  shipped  to  his  location.  The 
magnitude  of  this  problem  is  not  known  and  should  be  determined  before  the  type 
of  action  to  correct  the  problem  can  bo  decided  upon,  '\mong  the  possible  solutions 
would  be  a TM  receipt  system  or  some  form  of  communications  to  the  user  activities 


TABLE  3-7.  NTIPS  APPROACHES  TO  PROBLEMS  IN 
DISTRIBUTION 


Problem 


Approaches  to  TM/equipment  configura- 
tion management  are  inconsistent,  and 
distribution  control  functions  vary  among 
the  major  acquisition  activities. 

Distributed  TMs  occasionally  do  not  get 
to  the  actual  TM  user  although  they  do 
reach  the  ship,  NARF,  etc. 


NTIPS  Approach 

Use  STEDMIS/STEPS  and  supplement 
it  with  additional  pr()grams  to  provide 
total  automation  of  all  aspects  of  dis- 
tribution control  common  to  all  Navy 
activities. 

Problem  requires  further  research  to 
ascertain  frequency  of  occurrence, 
whether  it  is  limited  to  one  area  (ship- 
board, air  station,  etc,),  and  reasonable 
solutions. 
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3.9  TECHNICAL  APPROACH  TO  DISTRIBUTION  SUBSYSTEM  (Continued) 


The  operation  of  a centralized  TM  resupply  function  is  conceived  as  not 
too  different  from  the  existing  operations  of  NPFC.  However,  warehousing  and 
materiel  management  would  be  controlled  through  computer  programs  in  the  N TIPS 
MIS  for  inventory  control,  supply  actions,  and  the  like.  In  the  initial  concept,  resup- 
ply of  TMs  in  response  to  user  requests  would  not  be  a part  of  the  usual  "hardware" 
supply  system.  U would  be  separated  under  N ITPS  control  in  order  to  make  it  as 
responsive  as  possible  to  users'  needs.  A feature  to  be  added  iti  the  future  is  on- 
demand  replication  of  a copy  in  the  medium  requested  (paper  book,  mieroform,  digi- 
tal hologram,  etc.)  from  the  digital  data  base  of  the  working  archive.  This  approach 
would  greatly  minimize  and  ultimately  eliminate  the  need  to  keep  a predetermined 
number  of  copies  of  each  TM  in  the  specified  delivery  medium  until  (if  ever)  requested. 

Finally,  the  archive  function,  which  today  consists  of  various  assortments 
of  copies  of  printed  books,  photolithographic  negatives,  camera-ready  repro,  com- 
puter paper  or  magnetic  tape,  photographs,  and  line  artwork,  needs  consideration. 
These  items  do  not  reside  in  any  one  location.  They  may  be  at  an  equipment  con- 
tractor's facility,  a publications  service  contractor's  plant,  a Cognizant  Field  Ac- 
tivity (CFA),  a SYSCOM  headquarters,  or  at  NPFC.  The  latter  organization  does 
not  usually  receive  their  archive  copy  of  a TM  until  the  very  end  of  a contract. 

This  material  is  called  replenishment  material  and  usually  consists  of  two  copies 
of  a printed  book  and  glossy  prints  of  photographs.  This  then  becomes  the  historical 
archive,  although  the  material  stored  could  be  replicated  to  replenish  exhausted 
TU  stocks  or  to  create  masters  for  subsequent  updates.  The  NTIPS  preliminary 
concept  calls  for  a similar  historical  archive,  but  it  must  be  structured  and  controlled 
by  NTIPS.  Initially  the  TMs  would  be  stored  as  microforms;  and  digitally,  ultimately, 
if  and  when  determined  to  be  cost  effective. 

The  major  difference  in  the  NTIPS  approach  to  an  archive  function  is  in 
having  a working  archive  containing  a digital  data  base  of  all  active  TMs.  As  dis- 
cussed in  the  technical  approach  to  Publishing,  the  digital  data  base  is  developed 
principally  to  provide  a "TM  master"  that  can  be  processed  by  the  Navy  after  equip- 
ment transitions  from  in-production  to  out-of-production  status.  This  approach 
is  also  dependent  on  affordable  mass  memory  devices  being  available.  Since  graphics 
create  the  majority  of  digital  storage  requirements,  an  interim  digital  text,  visual 
storage  approach  may  be  needed.  The  historical  archive,  particularly  when  it  be- 
comes digital,  will  serve  as  an  effective  backup  for  the  working  archive. 
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FABLE  3-7.  NTIPS  APPROACHS  TO  PROBLEMS  IN 
DISTRIBUTION  (Continued) 


Problem 


I M resupply  is  part  of  the  overall  Navy 
supply  jystem  and  is  slow  to  respond  to 
users  needs. 


Physical  storage  of  copies  of  all  TMs 
for  resupply  purposes  uses  valuable 
space  and  is  cumbersome  to  operate. 


Present  Archive  consists  of  many  types 
of  TM  masters  (i.e.,  negs,  repro,  digital 
tape,  etc.)  in  many  different  locations 
(i.e.,  contractors,  CFA,  NPFC,  etc.) 


NTIPS  Approach 

Place  TM  resupply  under  NTIPS  and 
develop  automated  materiel  manage- 
ment into  NTIPS  MIS. 


Develop  capability  for  on-demand  repli- 
cation of  TM  in  medium  requested  (from 
digital  TM  data  base  of  Working  Archive). 
No  physical  storage  needed. 

Develop  centralized  archive  consisting 
of  master  copies  of  all  TMs  as  history 
and  a digital  data  base  of  all  active  TMs 
to  support  Navy  update  requirements. 


i 
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3.10  TECHNICAL  APPROACH  TO  MANAGEMENT  SUBSYSTEM 


I'he  main  problem  with  TM  management  lies  in  each  major  acquisition  activity  control- 
ling its  TM  operations  independently  with  no  thought  being  given  to  Navy-wide  TM  ef- 
forts. A two-tier  management  scheme  is  proposed  to  remedy  this  within  the  existing 
procurement  framework. 

The  NTIPS  Management  Subsystem  establishes  a first-level,  centralized 
NTIPS  management  function  to  coordinate  R&D  efforts,  perform  system  design, 
and  establish  operating  policies  and  quality  assurance  standards.  A second-level 
NTIPS  operations  management  function  is  established  to  control  the  TM  procure- 
ment and  production  activities.  This  two-tiered  management  approach  establishes 
both  levels  of  management  as  parts  of  NTIPS,  but  dedicates  the  second-level  NTIPS 
operations  management  function  to  the  TM  requirements  of  each  of  the  major 
acquisition  activities. 

TM  Funding  - TM  acquisition  funds  are  a part  of  new  equipment  budgets 
but  are  rarely  identified  separately.  By  being  hidden  in  the  overall  equipment 
funding,  the  acquisition  project  manager  (PM)  does  not  have  to  commit  any  specific 
amount  of  funds  to  TMs  and  may  divert  funds  needed  for  TMs  to  hardware  improve- 
ments or  design  changes. 

The  NTIPS  method  of  funding  will  be  to  have  the  hardware  acquisition 
PM  coordinate  with  the  second-level  NTIPS  Operations  Management  subfunction 
to  establish  the  TMs  needed  along  with  the  projected  TM  cost.  This  .vill  be  done  as 
early  as  possible  in  the  acquisition  process  and  will  be  used  by  the  PM  to  establish  the 
overall  TM  budget.  At  program  inception,  the  PM  will  receive  tiie  equipment  funds, 
while  the  second-level  N TIPS  Operations  management  subfunction  will  receive  the 
funds  identified  for  TMs  and  will  be  responsible  for  disbursing  the  funds  to  support 
the  TM  procurement. 

Systems  Management  Function  - The  first-level  system/product  improve- 
ment engineering  subfunction  performs  an  evaluation  of  the  quality  of  the  TM 
product.  This  subfunction  also  establishes  Navy-wide  TM  quality  assurance  (QA) 
policies  that  are  implemented  by  the  second-level  operations  management  function. 

The  cost  analysis/forecasting  subfunetion  performs  a periodic  in-depth 
analysis  of  system  TM  costs  and  operations  to  be  used  as  a tool  to  evaluate  NTIP 
System  performance  on  a Navy-wide  basis.  This  subfunction  also  is  responsible 
for  determining  the  impact  of  TMs  on  equipment  life-cycle  costs. 

The  research  and  development  (R3cD)  subfunction  coordinates  all  NTIPS- 
related  R<5cD  efforts  and  maintains  contact  with  DoD  and  industry  R&D  efforts 
to  preclude  redundancy  of  efforts  and  utilize  expertise  of  other  services. 

Management  Information  System  - The  NTIPS  Management  Information 
System  (MlS)  is  established  to  support  the  operations  of  the  NTIP  System  with 
cost  reports  that  can  aid  daily  operations  and  system  evaluation  by  different  NTIPS 
management  levels.  The  MIS  is  used  to  maintain  a data  base  that  lists  the  TM 
requirements  for  each  user. 

Operations  Management  Function  - The  second-level  management  feedback/ 
update  subfunction  provides  the  user  with  a reactive  feedback  point  that  is  responsive 
to  user  comments.  The  subfunction  also  is  responsible  for  reviewing  out-of-production 
TMs,  establishing  update  needs,  and  acting  as  the  PM  for  the  update  effort. 
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TABLE  3-8.  APPROACH  TO  NTIPS  MANAGEMENT 


Key  Problems 

Solutions 

No  Navy-wide  coordination  of  TM 
efforts 

Establish  two-tiered  NTIPS  management 
subsystem  that  has  a centralized  first- 
level  management  function  to  control 
and  coordinate  second-level  operations 
management  functions. 

No  dedicated  funds  for  TM  efforts 

All  TM  funds  are  identified  in  overall 
equipment  budget  and  dedicated  for 

NTIPS  control  at  prog.-am  inception. 

No  comprehensive  product  evaluation 

Assigned  to  the  first  management  level 
(system/product  improvement  engineer- 
ing subfunction) 

No  consistent  Navy-wide  quality 
assurance 

Assigned  to  the  first  mangement  level 
(system/product  improvement  engineer- 
ing subfunction) 

No  in-depth  analysis  of  Navy  TM  costs 
or  operations 

Assigned  to  the  first  management  level 
(cost  analysis/forecasting  subfunction) 

No  studies  of  impact  of  TMs  on  weapon 
life  cycle  costs 

Assigned  to  first  management  level 
(cost  analysis/forecasting  subfunction) 

No  cohesive  Navy-wide  controlled 

R&D  efforts  ' 

1 

First  management  level  RdcD  subfunction 
coordinates  all  NTlPS-related  Navy  R3cD 
efforts 

No  comprehensive  data  base  of  Navy 

TM  costs  or  operations  i 

Establish  the  NTIPS  Management  Inform- 
ation System  (MIS). 

No  Navy-wide  TM  configuration  index  j 

Implement  Navy-wide  configuration 
system  and  store  data  in  the  MIS. 

No  viable,  reactive  user  feedback 
contact  point 

Assigned  to  the  second  management 
level  (feedback/update  subfunction) 

1 

No  consistent  plan  for  management 
of  out-of-production  TMs. 

Assigned  to  the  second  management 
level  (feedback/update  subfunction) 
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Section  3 - Preliminary  NTIP  System  Concept 


3.10  METHOD  FOR  UPDATING  TECHNICAL  MANUALS 


I 


I'he  same  organizational  structure  is  used  to  update  TMs  as  that  employed  in  the  acquis- 
ition of  the  I'Ms.  Hardware-related  updates  are  initiated  and  funded  by  the  equipment 
acquisition  manager,  while  nonhardware-related  or  out-of-production  updates  are 
the  responsibility  of  the  NTIPS  Management  Subsystem  (feedback/update  subfunction). 

Within  the  Navy,  there  are  currently  two  approaches  to  technical  manual 
updates;  revisions  and  changes.  A revision  constitutes  a complete  new  erlition  of 
an  existing  manual.  This  generally  will  occur  as  a result  of  one  or  inore  of  the 
following: 

• A major  change  in  equipment  configuration 

• Existence  of  a high  percentage  of  miscellaneous  outstanding  source  data 

• Issuance  of  another  change  package  would  tend  to  confuse  rather  than 
complement  the  document 

• The  intended  accumulated  changes  will  impact  30  to  60  percent  of  the 
total  number  of  TM  pages. 

A change  is  issued  when  only  relatively  small  parts  of  an  existing  manual 
are  affected.  The  changed  pages  replace  the  correspondingly  numbered  pages,  and 
all  replaced  pages  must  be  removed  and  discarded.  If  a change  contains  material 
that  cannot  be  fully  included  on  a replacement  page,  additional  pages  are  issued 
and  inserted  between  or  after  the  affected  pages.  Changes  are  prepared  to  include 
new  models  of  equipment  and  to  add  new  procedures,  or  to  change  existing  equip- 
ment descriptions  or  procedures.  Manuals  of  eight  pages  or  less  are  normally  re- 
placed by  a revision.  Also,  microform-compatible  manuals  of  30  pages  or  less  are 
replaced  by  a revision  rather  than  a change. 

Updates  can  also  be  grouped  into  two  other  categories,  depending  upon  how 
they  are  originated.  Hardware-related  updates  are  a consequence  of  modifications 
to  the  system/equipment  configuration.  These  are  generally  originated  in  conjunc- 
tion with  scheduled  hardware  alterations  (SHIPALTs  and  ORDALTs)  or  engineering 
change  proposals  (ECPs).  Nonhardware-related  updates  are  generally  user-initiated 
in  an  attempt  to  correct  technical  inaccuracies,  provide  for  the  inclusion  of  addi- 
tional information,  or  to  clarify  ineffective  graphic  presentations.  These  are  in- 
itiated via  fleet  feedback  reports  (Fl3Rs). 

In  the  NTIPS  preliminary  system  concept,  the  Management  Subsystem  is 
responsible  for  the  control  and  funding  of  all  TM  updates.  The  funds  required  for 
hardware-related  updates  are  appropriated  by  the  equipment  acquisition  manager 
at  the  same  time  that  the  allocation  of  funds  for  the  equipment  modification  is 
made.  These  update  funds  are  then  transferred  to  the  Mangement  Subsystem.  Non- 
hardware-related updates  are  funded  directly  by  the  Management  Subsystem  (feed- 
back/update subfunction).  The  Management  Subsystem  provides  guidelines,  to  the 
Acquisition  Subsystem,  which  establish  the  configuration  control  and  quality  assur- 
ance policies/procedures  required  to  insure  continuity  and  consistency  between  the 
original  and  updated  TMs. 

Another  consideration  regarding  TM  update  involves  the  development  of 
a digital  data  base  containing  all  technical  manuals  used  in  the  Navy.  This  is  a part 
of  the  NTIPS  preliminary  system  concept  and  would  include  the  equipment  contract- 
or's TM  data  base  (when  initial/original  issue  TMs  arc  delivered).  These  TMs  would 
be  stored  in  a structured  digital  data  base  containing  all  current  TMs  for  in-pro- 
duction equipment,  thus  assuring  archival  availability.  When  equipment  transitions 
from  in-production  to  out-of-production  status,  it  is  assured  that  there  would  be 
a current  data  base  to  permit  the  Navy  to  update  TMs  for  out-of-production  equip- 
ment. The  same  data  base  could  just  as  readily  be  used  for  Navy  updating  of  TMs 
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for  in-production  manuals  in  the  event  of  contractor  default,  emergency  require- 
ments, or  other  operational  factors.  This  concept  would  provide  for  the  internal 
Navy  processing  of  TM  updates  in  a rapid  and  efficient  manner.  The  decision  to 
implement  this  option  (for  in-production  equipment  updates  by  the  Navy)  would, 
however,  remain  a matter  for  policy  decision  and  does  not  constitute  a requirement 
for  the  preliminary  system  concept. 

Processing  the  TM  Update  - Once  the  requirement  for  a T.M  update  has 
been  established,  the  procedures  for  acquisition,  development,  production,  and  dis- 
tribution are  the  same  for  both  hardware-related  and  nonhardware-related  updates. 
The  distinction  between  the  two  thus  resides  in  the  initiation  of  the  update  require- 
ment. 

Hardware-related  update  requirements  can  arise  as  a result  of  ECP,  opera- 
tional alteration  tOPALT),  or  scheduled  hardware  changes.  As  illustrated  in  Fig- 
ure 3-3,  these  requirements  will  generally  originate  with  project/acquisition  man- 
agement, or  a cognizant  field/technical  activity.  Once  the  TM  update  cycle  has 
been  initiated,  the  Management  Subsystem  monitors  the  TM  update  status  via  the 
Management  Information  System  (MIS). 


Figure  3-3.  TM  Upd;.te  System  for  Hardware-Related  Updates 
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3.11  METHOD  FOR  UPDATING  TECHNICAL  MANUALS  (Continued) 


As  Figure  3-4  illustrates,  nonhardware-related  updates  are  generally  in- 
itiated by  the  user.  There  are  three  approaches  to  feedback  in  the  preliminary  sub- 
system concept:  these  involve  (1)  the  use  of  NTIPS  field  representatives,  (2)  an 
NTIPS  on-going  fleet  survey,  or  (3)  a feedback  report  (FBR)  from  the  user. 

The  first  of  these  approaches  would  involve  the  stationing  of  NTIPS  repre- 
sentatives (who  would  be  TM  experts)  at  major  Navy  installations.  These  represent- 
atives would  assist  the  TM  user  with  data  problems  and  assist  in  the  preparation 
of  the  feedback  reports.  In  this  latter  role,  the  field  representative  could  serve 
to  expedite  the  processing  of  the  FBR  by  insuring  the  clear  and  accurate  comple- 
tion of  the  forms.  Additionally  the  NTIPS  representative  would  provide  on-the-spot 
training  in  TM  use,  such  as  the  application  of  maintenance  dependence  charts,  logic 
state  tables,  etc. 

The  conduct  of  an  on-going  fleet  survey  would  be  established  and  maintained 
by  the  feedback/update  subfunction  within  the  NTIPS  Management  Subsystem.  This 
would  entail  actively  soliciting  feedback  from  the  user.  Compiling  this  information 
for  later  analysis  would  aid  in  formulating  solutions  to  TM  problems. 

Both  of  these  approaches  would  provide  data  to  the  feedback/update  sub- 
functions. Additionally,  however,  some  advantages  should  be  realized  in  providing 
for  a method  of  collecting  data  that  often  is  precluded  by  the  use  of  paper  work. 
Data  would  be  obtained  via  face-to-face  contact  with  the  user,  permitting  clarifi- 
cation and  (where  appropriate)  elaboration  of  the  problem(s)  being  reported  by  the 
user.  Such  data  would  include  more  explicit  information  of  the  user's  appraisal  of 
such  things  as  TM  form,  organization,  and  illustration  techniques,  and  problems 
encountered  while  using  the  TM. 

The  third  approach  is  the  use  of  the  feedback  report.  The  FBR  is  a telecon. 
Navy  message,  or  a standard  form  (for  routine  problems^  The  FBR  standard  form 
will  be  a TM-unique  document  that  will  be  designed  to  expedite  TM  problem  infor- 
mation flow  from  the  user  to  the  feedback/update  subfunction. 

The  feedback/update  subfunction  logs  the  FBR  and  performs  a preliminary 
review  to  determine  if  the  problem  presented  warrants  investigation.  If  it  is  deter- 
mined that  no  investigation  is  needed,  the  user  (who  submitted  the  FBR)  is  notified 
of  this  fact  and  the  rationale  for  the  decision.  If  it  is  determined  that  investigation 
is  warranted,  the  FBR  is  forwarded  to  the  cognizant  activity  (equipment  contractor 
for  in-production  equipment  or  cognizant  Navy  field/technical  activity  for  out-of- 
production equipment). 

To  be  responsive  to  user  needs,  all  requirements  are  reviewed  and  categor- 
ized by  the  feedback/update  subfunction  into  one  of  three  priority  classifications; 

(1)  emergency,  (2)  urgent,  or  (3)  routine.  An  emergency  priority  requires  immedi- 
ate correction  to  alleviate  conditions  that  could  cause  injury  to  personnel,  exten- 
sive damage  to  equipment  or  property,  or  an  inability  to  maintain  equipment  in  an 
operational  condition.  An  urgent  priority  requires  prompt  correction  to  alleviate 
a condition  that  could  result  in  damage  to  equipment  or  property,  a reduction  in 
equipment  operational  efficiency,  or  jeopardize  the  successful  completion  of  a mis- 
sion. A routine  priority  involves  normal  TM  improvement  (clarification,  editorial, 
simplification),  potential  personnel/equipment  hazards  with  prolonged  use,  or  a re- 
duced operational  equipment  life. 

A requirement  having  an  emergency  priority  will  be  responded  to  within 
three  calendar  days.  Corrective  action  will  be  sent  via  Naval  message  to  the  re- 
porting organization  as  well  as  all  other  organizations  affected  by  the  emergency. 
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Ten  working  days  will  be  allowed  for  corrective  action  requirements  having  an  "ur- 
gent" priority.  Speed  letters  will  be  used  to  respond  to  the  reporting  organization 
and  to  communicate  required  corrective  action  to  all  affected  organizations.  For 
routine  priorities,  the  reporting  organization  will  receive  an  acknowledgement  (feed- 
back response)  within  10  working  days,  and  corrective  action  will  be  initiated  within 
60  working  days  of  requirement  receipt. 

The  cognizant  activity  performs  a technical  evaluation  of  the  FBR  and  pro- 
vides a solution  to  the  problem  as  soon  as  possible,  but  always  within  the  time  con- 
straints of  the  assigned  priority.  In  the  event  no  TM  changes  are  necessary,  the 
FBR  response  must  contain  the  rationale  for  the  decision.  When  a TIVl  update  is 
required,  the  TM  update  cycle  is  initiated  by  the  cognizant  activity. 

The  Management  Subsystem  will  monitor,  via  the  MIS,  the  status  of  both 
the  FBR  and  the  TM  update  cycle.  Information  contained  in  the  MIS  will  be  applied 
to  improving  the  efficiency  and  cost  effectiveness  of  the  feedback/update  process. 


Figure  3-4.  TM  Update  and  Feedback  System  for  Nonliardware-Related  Updates 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4.1.1  DESCRIPTION  OF  TM  ACQUISITION  SUBSYSTEM 


The  preliminary  concept  for  TM  acquisition  is  that  of  decentralized  subsystems  within 
NTIPS  that  are  dedicated  to  each  major  acquisition  activity.  These  subsystems  would 
specify  precise  data  requirements  for  their  particular  users  and  implement  procure- 
ment procedures  to  ensure  timeliness  and  quality  in  TMs. 

The  TM  Acquisition  Subsystem  analyzes  the  initial  data  requirements  for 
a TM  procurement,  performs  a user-data  match,  generates  specifications  to  define 
the  TM  requirements,  develops  contract  documents,  and  initiates  the  acquisition 
processes  to  purchase  TMs  from  the  content  generators  (see  Figure  4-1). 

New  concepts  for  the  TM  Acquisition  Subsystem  would  include:  (1)  formal 
matching  of  the  data  to  the  particular  user,  (2)  automated,  modular  TM  specifica- 
tions, (3)  TM  procurement  activities  that  are  run  by  specialized  "Navy  TM  Engi- 
neers," and  (4)  new  TM  funding  structures.  These  new  aspects  to  TM  acquisition 
are  considered  critical  to  the  mission  effectiveness  of  the  subsystem.  TM  acquisi- 
tion is  the  place  where  many  TM  problems  can  be  solved,  long  before  TM  production 
is  initiated.  Improper  decisions  on  TM  requirements  and  specifications  in  this  sub- 
system will  result  in  substandard  TM  products  downstream,  where  corrections  are 
costly  or  impossible. 

User-Data  Match  Function  - The  user-data  match  function  matches  the 
tasks  a specified  user  must  perform  on  particular  equipments  in  known  environments 
to  the  information/presentation  types  he  can  best  utilize  to  perform  the  tasks. 

A matrix  model  is  employed  in  the  matching  process  which  interrelates  information 
concerning  user  personnel  characteristics,  system  conditions,  environments,  media 
types,  and  components  of  data  presentation  systems.  The  user-data  match  function 
is  described  more  fully  in  the  following  topic. 

The  output  of  the  matching  process  is  a designation  of  presentation  compon- 
ents and  systems,  e.g.,  tables,  charts,  text  treatments,  diagram  types,  etc.,  speci- 
fically matching  a particular  user  rating  to  his  types  of  tasks.  If  new  presentation 
techniques  have  been  identified  for  which  no  specification  modules  are  available, 
then  the  specification  function  would  generate  new  specifications  for  the 
procurement. 

TM  Specification  Function  - The  TM  specification  function  generates  spec- 
ifications  that  define  to  content  generators  the  expected  content,  quality  control 
provisions  and  standards  that  must  be  achieved  in  the  development  of  TMs.  The 
preliminary  concept  proposes  a TM  specification  function  within  the  NTIPS  organiza- 
tional structure  that  is  dedicated  to  each  major  acquisition  activity.  Each  of  these 
functions  would  utilize  an  automated,  modular,  TM  specification  structure. 

Using  a modular  specification  concept,  a complete  TM  specification  would 
be  built  from  a variety  of  many  specification  modules.  Modules  would  be  combined 
as  necessary  to  describe  the  complete  requirements  for  a particular  TM  procurement. 
Specification  modules  would  describe  different  types  of  data  and  the  requirements 
to  which  each  type  must  conform,  as  well  as  publishing  processes  for  various  media, 
quality  control  guidelines,  etc. 

Specification  modules  would  be  prepared,  maintained,  and  implemented  for 
use  by  a computer-aided  specification  preparation  system.  The  Navy  TM  engineer, 
who  is  a part  of  the  TM  procurement  function,  would  access  this  automated  speci- 
fication system  when  all  user  information  requirements  have  been  identified.  He 
would  select  from  various  module  categories  those  modules  that  describe  TM  require- 
ments for  the  identified  user  needs.  He  may  select,  for  example,  50  or  more  speci- 
fication modules  from  a much  larger  number  of  stored  modules,  to  form  the  TM 
specification  for  a given  procurement.  The  automated  specification  preparation 
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system  would  retrieve  these  modules  and  format  and  output  them  as  a single  specifi- 
cation document.  It  would  also  be  possible  to  add  or  delete  modules  from  those 
in  storage  and  to  perform  continuous  and  rapid  updates  by  means  of  this  system. 

TM  Procurement  Function  - The  procurement  function  is  responsible 
for  negotiating  the  purchase  of  the  TM.  In  performing  this  function  it  develops 
TM  contract  documents,  participates  in  negotiations  with  content  generators,  and 
provides  quality  control  of  the  TM  development  process,  all  the  way  to  the  final 
buy-off.  Each  of  the  TM  procurement  functions  within  NTIPS,  though  dedicated 
to  the  purchase  of  TMs  for  a major  acquisition  activity,  would  be  a part  of  the  N flPS 
organizational  structure  and  operate  within  its  management  and  operational  guide- 
lines. Other  features  of  the  preliminary  concept  include  a Navy  TM  engineer  who 
would  oversee  the  operations  of  each  function,  and  a funding  structure  that  would 
prohibit  other  activities  from  dipping  into  funds  that  have  been  allocated  for  TMs. 

Organizational  Alternatives  - A decentralized  alternative  would  place 
the  subsystem  within  the  organizational  structure  of  each  major  acquisition  activity, 
but  subject  to  guidelines,  policies,  and  procedures  from  NTIPS.  Another  alternative 
is  to  centralize  the  subsystem  within  the  NTIPS  organizational  structure.  This  single 
central  activity  would  provide  functional  capabilities  for  all  Navy  major  acquisition 
activities. 


Figure  4-1.  TM  Acquisition  Subsystem.  The  TM  Acquisition  Subsystem  analyzes  the  broad  spectrum 
of  users,  equipment,  tasks,  environments,  and  presentation  techniques  to  generate  TM  specif'cations 
and  to  develop  TM  acquisition  processes  and  procedures  for  supplying  Navy  users  with  quality  techni- 
cal manuals. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 


4.1.2  DESCRIPTION  OF  USER-DATA  MATCH  FUNCTION 


The  basic  inadequacy  of  'I'M  presentation  methods  lias  been  due  to  their  not  being  what 
tlie  user  needs  to  do  his  job.  An  NTIPS  contribution  to  the  solution  is  a user-data  match 
model  that  would  aid  Navy  personnel  in  matching  the  presentation  techniques  to  the 
user  before  the  data  is  procured. 

Technical  information  provided  to  maintenance  technicians  who  support 
fleet  activities  is  cited  in  various  surveys  and  research  studies^  as  failing  to  present 
information  uniquely  suited  to  the  needs  of  a particular  user  group.  This  failure 
substantially  inhibits  the  timely  and  economical  maintenance  of  operationally  impor- 
tant equipment. 

In  order  to  alleviate  this  problem,  the  presentation  techniques  in  'FMs  must 
be  more  closely  matched  to  the  unique  characteristics  of  the  user,  the  job  tasks 
which  the  user  will  perform  (using  the  TW),  and  the  environment  in  which  the  user 
will  perform  these  tasks.  'Fhe  purpose  of  the  user-data  match  function  is,  therefoi'e, 
to  accomplish  this  match  and  provide  user-data  match  recommendations  to  the  TM 
specification  function.  These  recomniemiations  niiiit  clearly  identify  the  i presen- 
tation techniques  and  the  media  features  w appij  to  th_  3\ '.tem/envircnnient 
as  a whole,  and  would  therefore  be  useful  as  guidelines  to  the  TM  engineer  in  the 
development  of  TM  bookplans. 

The  whole  job  of  making  a better  user-data  match  includes  the  collection 
of  information  regarding  the  user  and  his  needs,  in  the  form  of  personnel  character- 
istics, equipment  characteristics,  working  environment,  and  the  maintenance  tasks. 
This  information  would  be  derived  from  data  analyses  of  specific  procurements  which 
are  provided  by  activities  external  to  the  NTIP  System  that  perform  the  system 
acquisition  process,  and  by  integrated  logistic  support  (ILS)  activities.  Such  analyses 
continue  throughout  the  content  generation  phase  until  a detailed  TM  design  is 
achieved  that  effectively  meets  the  reader's  needs. 

An  important  part  of  this  process  is  the  initial  user-data  matching  that  can 
be  done  early  in  the  program  by  NTIPS  to  assist  in  the  selection  of  the  TM  specifi- 
cations. This  would  consist  of  determining  the  categories  of  maintenance  tasks 
which  correspond  to  the  kind  of  equipment  components  involved  in  the  procurement. 
From  this,  key  aspects  of  the  presentation  methods  and  media  can  be  determined 
long  before  detailed  task  analyses  are  available  from  external  maintenance 
organizations. 

Concept  of  the  User-Data  Match  Model  - The  preliminary  concept  proposes 
a model  for  use  in  matching  the  presentation  methods  to  Navy  ratings.  As  shown 
in  Figure  4-2,  the  user-data  match  model  consists  of  three  matrices.  The  matrix 
on  equipment  type  and  maintenance  level  vs.  task  action  is  unique  to  a particular 
Navy  rating  (or  grouping  of  highly  similar  ratings).  The  matrix  identifies  the  types 
of  equipments  that  a rating  may  be  expected  to  operate  or  maintain,  and  the  task 
actions  which  are  delegated  to  this  rating.  The  second  matrix  identifies  the  presen- 
tation techniques  or  components  which  the  rating  can  best  utilize  in  performing 
the  task  actions  identified  on  the  previous  matrix.  These  may  be  identified  us  types 
of  schematic  diagrams,  text  treatments,  procedure  formats,  etc.  This  matrix,  like 
the  first,  is  unique  to  a particular  rating  or  group  of  ratings.  It  then  remains  to 
use  the  third  matrix  to  extract  the  physical  characteristics  of  the  medium  for  the 
environment  of  intended  use. 


Hughes  Aircraft  Company;  Special  Report  - NTIPP  Fleet  Survey  of  Technical  Man- 
ual Users;  5 March  1977,  David  W.  Taylor  Naval  Ship  Research  and  Development 
Center. 
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riie  output  of  the  user-data  matching  process  would  consist  of  a prioritized 
list  of  recommendations  concerning  the  media  and  presentation  techniques  to  be 
employed  in  presenting  technical  information  (for  every  task  action!  to  the  user. 

I'his  informatioti  would  tlien  be  forwarded  to  the  IMavy  T.\l  engineer  within  t!ie  1 *i 
procurement  function.  The  Navy  Ti\i  engineer  would  then  select  the  presentation 
toctiniques  and  media  features  to  be  specified  for  the  T.\l  procurement.  This  -<  lec- 
tion would  also  be  based  ufK'i.  :..c  af  icruability  of  the  requirements/recommendations 
for  that  procurement.  Based  upon  the  presentation  technique  and  media  selected, 
the  TM  specification  function  would  compile  the  specification  modules.  These  speci- 
fication modules  'would  then  be  sent  to  the  TM  procurement  function  as  part  of  the 
fAi  specification  package.  Ultimately,  this  package  would  be  used  by  the  contractor 
TM  engineer  as  the  initial  basis  for  the  TM  design. 

Primary  data  sources  for  support  of  the  model  are  the  Navy  Bureau  of  Per- 
sonnel and  the  Navy  Occupational  Task  Analysis  Program.  These  sources  provide 
the  data  base  from  which  personnel  characteristics  and  general  equipment/task 
analysis  information  for  the  user-data  match  model  are  derived.  Primary  respon- 
sibilities of  the  NTIPS  user-data  match  function  include  keeping  the  model  current 
with  data  presentation  technologies  and  exercising  the  model  on  demand  to  pro- 
vide the  TA'l  specification  function  with  the  presentation  recommendations. 

A detailed  discussion  of  the  concept  of  the  user-data  match  model  will  be 
found  in  the  Task  3 Report  Addendum. 

Organization  Alternatives  - The  preliminary  concept  is  for  each  major  ac- 
quisition activity  to  have  its  own  user-data  match  function.  Having  selected  the 
decentralized  approach,  a further  organizational  option  is  available.  The  function 
established  for  each  major  acquisition  activity  could  be  organizationally  either  part 
of  that  activity  or  part  of  the  NTIP  System  but  dedicated  to  the  major  acquisition 
activity's  particular  requirements.  An  additional  alternative  consists  of  acentral- 
ized  function  that  has  user-data  match  responsibility  for  all  TM  Procurements  for 
all  Navy  major  acquisition  activities. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4.1.3  DESCRIPTION  OF  TM  SPECIFICATION  FUNCTION 


Present  specifications,  written  loosely  to  cover  a large  variety  of  equipments,  do  not 
provide  sufficient  guidance  for  content  generators  to  produce  a TM  that  satisfies  the 
needs  of  a particular  user.  The  preliminary  concept  corrects  this  by  defining  a modu- 
lar specification  system  that  enables  a unique  specification  to  be  tailored  to  the  spe- 
cifie  TM  procurement. 

Due  to  the  overgeneralization  of  specifications,  contractors  are  often  left 
to  interpret  detailed  format  and  content  requirements.  Such  interpretations  differ 
from  one  contractor  to  another,  and  may  also  differ  from  what  was  intended  by  the 
procuring  activity.  For  example,  a single  specification  may  be  cited  for  the  pro- 
curement of  operation  and  maintenance  manuals  for  a complex  electronic  system, 
an  electromechanieal  assembly,  and  mechanical  equipment.  The  contractor,  in  at- 
tempting to  interpret  how  the  specification  can  be  applied  to  a TM,  can  decide  on 
an  approach  that  is  other  than  that  intended  by  the  proeuring  activity,  but  is  in  com- 
pliance with  specification  requirements. 

TM  Specification  Function  - The  TM  specification  function  is  responsible 
for  developing  specifications  that  dictate  a complete  spectrum  of  TM  requirements. 
These  requirements  are  encompassed  in  categories  such  as  technical  content,  pre- 
sentation techniques,  quality  control,  access,  readability,  and  publishing.  What 
is  specifically  required  in  each  of  these  categories  is  determined  primarily  by 
variables  such  as  system  and  equipment  types  in  use  by  the  Navy,  operational 
and  maintenance  philosophies,  user  personnel  skill  levels,  and  state-of-the-art  in 
data  presentation  and  media  technologies.  The  user-data  match  model  will  identify 
a set  of  presentation  methods  to  effect  a good  user-data  match.  This  will  provide 
guidance  to  the  TM  specification  function  for  developing  TM  specification  require- 
ments that  must  be  available  for  each  of  the  categories  listed  above. 

As  new  presentation  methods  are  developed  in  the  future,  the  TM  specifi- 
cation function  will  propose  and  develop  new  specification  requirements  to  incor- 
porate them.  This  information  will  be  obtained  via  the  NTIPS  Management  Sub- 
system which  maintains  a constant  data  exchange  liaison  with  other  service 
branches.  The  NTIPS  Management  Subsystem  research  and  development  function 
will  also  provide  guidance  for  specification  development,  especially  in  the  area  of 
quality  control  guidelines  and  new  data  presentation  technologies. 

Specifications  can  be  generated  by  manual  or  automated  methods.  Current 
generation  and  update  of  Navy  TM  specifications  is  by  manual  methods.  Many 
government  agencies  and  commercial  companies  presently  utilize  automated  tech- 
niques in  the  generation  of  various  types  of  specifications.  Both  methods  will  be 
explored  for  application  to  NTIPS  TM  specifications. 

The  preliminary  concept  for  the  TM  specification  organization  is  for  each 
major  acquisition  activity  to  have  its  own  function.  Having  selected  a decentral- 
ized approach  a further  organizational  option  is  available.  The  function  establish- 
ed for  each  major  acquisition  activity  could  be  organizationally  either  part  of  that 
activity  or  part  of  the  NTIP  System  but  dedicated  to  the  major  acquisition  activity. 

Modular  Specification  Approach  - The  preliminary  concept  for  development 
of  NTIPS  TM  specifications  involves  a modular  structure  for  presentation  of  spe- 
cifications requirements.  Modular  specifications  are  developed  from  modular  parts 
of  a master  specification  structure  (see  Figure  4-3).  All  the  modules  are  orga- 
nized into  six  different  categories,  which  encompass  the  complete  spectrum  of 
requirements  for  TMs  for  a variety  of  equipments,  users,  and  Navy  maintenance 
philosophies.  For  example,  modules  in  the  technical  content  category  will  include 
site  preparation  instructions,  system  functional  descriptions,  functional/pcrformance 
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tests,  etc.  Those  contained  in  the  presentation  techniques  category  will  includ( 
text,  illustrations,  tables  and  matrices,  diagrams  with  supporting  text,  etc.  Mo 
are  developed  to  be  compatible  for  use  with  each  other  in  specifying  total  TM  i 
quirements.  The  total  specification  requirements  for  a TM  may  be  composed  o 
one  or  more  modules  selected  from  each  category.  Generating  a TM  specificat 
by  this  technique  permits  custom  tailoring  of  specifications  to  an  individual  da1 
procurement.  In  addition,  those  specification  modules  will  contain  detailed  ste 
by-step  instructions  and  examples,  eliminating  the  need  for  a separate  writers 
guide. 

In  developing  a modular  specification,  the  basic  TM  requirements  of  thi 
user  will  be  extracted  from  the  user-data  match  model.  These  will  include  a tt 
versus-equipment  analysis,  presentation  techniques  the  user  will  need  to  perfor 
his  task,  and  media  considerations  for  the  user  environment.  Additional  TM  cri 
include:  training  requirements,  available  funding,  and  Navy  maintenance  requi 
ments  for  the  system/equipment  for  which  the  TMs  are  being  procured. 

The  TM  procurement  function  will  analyze  these  TM  requirements  and 
select  modules  from  each  category  to  define  the  complete  TM  specification. 
Some  of  the  categories  will  be  organized  and  capable  of  direct  access  once  the 
specific  TM  requirements  have  been  identified.  For  example,  presentation 


Figure  4 3.  TM  Specification  Evolution  Process.  Modular  TM  specifications  will  be  geners 
master  file  that  contains  sets  of  TM  requirements  in  distinctive  categories. 
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techniques  modules  will  have  direct  correlation  with  those  identified  by  the  user- 
data  match  model.  Readability  modules  may  be  accessed  from  a knowledge  of 
user  personnel  characteristics,  including  reading  grade  level.  Access  and  publishing 
process  modules  will  be  selected  based  on  the  type  of  manual  and  medium  by  which 
it  is  produced.  Other  module  selections  will  be  made  drawing  upon  the  expertise 
of  the  TM  procurement  personnel  or  by  guidelines  issued  to  these  personnel  from 
the  NTIPS  Management  Subsystem,  especially  in  the  area  of  quality  control.  In- 
dividual modules  may  vary  in  size  from  one  paragraph  to  many  pages.  For  example, 
a module  describing  the  step-by-step  development  of  a type  of  illustration  could 
be  quite  lengthy,  whereas  a module  describing  classification  markings  could  be 
contained  on  one  page  or  less. 

Based  on  the  large  numbers  of  procurements  and  quantities  of  modules, 
many  manipulations  of  the  various  modules  will  be  required  to  develop  a unique 
specification  package  for  a given  procurement.  Consequently,  the  capability  to 
input  the  unique  procurement  requirements  into  a programmed  processor  which 
would  then  select  and  output  the  appropriate  specifications  is  considered  as  part 
of  the  preliminary  concept.  In  addition,  automation  would  enhance  updating  the 
specification  system,  providing  the  capability  to  keep  the  modules  current  with 
state-of-the-art  innovations  in  data  presentation  techniques. 

Monolithic  Specification  Alternative  - Monolithic  specifications  are  general 
application  type  specifications  that  list  TM  requirements  for  a class  of  Navy  equip- 
ments, or  particular  type  of  TM,  or  a particular  Navy  operation  or  maintenance 
activity.  As  general  specifications,  their  broad  coverage  enables  them  to  be  used 
without  respect  to  discipline  (i.e.,  mechanical,  electrical,  etc.).  An  undesirable 
feature  of  this  type  of  specification  is  that  it  must  be  "force  fit"  to  some  TM  procure- 
ments. This  is  presently  done  with  tailoring  documents  that  must  be  prepared  as 
a part  of  the  contract  document  for  each  TM  procurement  action.  In  some  cases 
several  of  these  general  purpose  specifications  are  necessary  to  describe  the  com- 
plete TM,  with  liberal  referencing  from  one  specification  to  another  to  cover  all 
TM  requirements.  This  also  causes  a tailoring  operation  to  invoke,  exclude,  or  super- 
sede parts  of  some  of  the  specifications  for  a particular  TM  procurement. 

To  remedy  this  problem,  NTIPS  monolithic  specifications  would  be  built 
around  specific  system/equipment  categories  and  special  groups  of  users  (e.g.,  oper- 
ator and  maintenance  personnel).  For  example,  the  monolithic  specification  for 
communications  systems  would  include  requirements  for  all  Navy  users  who  would 
operate  or  repair  communications-related  equipment  (e.g.,  radio  transmitters,  re- 
ceivers, multiplexing,  etc.)  at  organizational,  intermediate  or  depot  facilities.  Thus, 
NTIPS  monolithic  specifications  would  contain  no  external  referencing  for  primary 
technical  content,  i.e.,  each  monolithic  specification  would  contain  requirements 
for  complete  operation  and  maintenance  data. 

Organizational  Alternatives  - Organizational  alternatives  are  important 
because  they  impact  cost  and  performance  effectiveness  of  the  function  as  well 
as  the  effectiveness  of  the  specification  itself  in  doing  the  job  for  which  it  is  in- 
tended. The  TM  specification  function  can  be  decentralized  as  in  the  preliminary 
concept,  i.e.,  each  major  acquisition  activity  can  have  its  own  function  and  in- 
dividualized TM  specifications,  or  the  function  can  be  centralized.  Centralization 
of  the  function  offers  potential  cost  savings  in  combining  redundant  operations. 

It  also  allows  better  central  control  for  standardization  of  the  specification  pro- 
duct. On  the  other  hand,  a decentralized  TM  specification  function  favors  each 
major  acquisition  activity's  dedication  to  its  particular  requirements. 
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4. 1.3.1  DESCRIPTION  OF  TECHNICAL  CONTENT  SPECIFICATIONS 


In  modular  specifications,  the  TM  content  requirements  are  related  to  one  user's  need 
and  presented  in  terms  of  specific  system/equipment  characteristics  and  Navy  mainte- 
nance levels.  The  result  is  a custom-tailored  TM  specification  that  precisely  defines 
technical  content  requirements,  such  as  equipment  operation  and  functional  description. 

Technical  content  requirements  encompass  the  type  and  depth  of  user  infor- 
mation necessary  to  perform  operational  and  maintenance  functions  on  Navy 
system/equipments.  Information  types  may  consist  of  procedures  such  as  correc- 
tive and  preventive  maintenance,  operation,  installation,  and  overhaul,  and  func- 
tional descriptions  of  the  system,  equipment,  basic  circuits  and  assemblies,  etc. 

The  depth  of  the  information  is  dependent  upon  the  complexity  of  the  system/ 
equipment  and  the  Navy  maintenance  philosophy  that  determines  to  what  degree 
the  system/equipment  is  to  be  repaired  at  various  Navy  maintenance  levels,  i.e., 
organizational,  intermediate,  and  depot.  For  example,  circuit  card  removal  and 
replacement  may  be  the  maintenance  philosophy  at  the  organizational  repair  level 
for  a particular  piece  of  equipment.  In  this  case,  organizational  personnel  will  need 
a type  of  troubleshooting  information  that  enables  isolation  and  replacement  of 
the  defective  circuit  card,  but  will  require  no  depth  of  coverage  beyond  this  for 
the  circuit  card.  The  type  of  troubleshooting  information  that  is  required  to  locate 
the  defective  card  could  be  simple  or  sophisticated  depending  on  the  type  of  equip- 
ment. For  example,  troubleshooting  information  for  a magnetic  tape  transport  with 
a complement  of  ten  circuit  cards  would  be  much  simpler  than  troubleshooting  in- 
formation for  a large  signal  processor  with  a hundred  or  more  circuit  cards. 

Present  Navy  TM  specifications  attempt  to  cover  technical  content  require- 
ments for  all  equipment  types  in  a single  primary  content  specification.  Most  of 
the  technical  content  requirements  of  the  specification  are  not  sufficiently  explicit 
for  application  to  all  equipment  types.  In  many  cases,  it  is  up  to  the  contractor 
to  decide  which  type  of  technical  content  is  applicable  to  which  type  of  equipment, 
or  to  invent  his  own  in  many  cases.  Because  of  the  broad  coverage  of  the  primary 
content  specifications,  unique  technical  content  requirements  are  not  provided  for 
unique  equipment  types.  For  example,  specifications  that  describe  specific  tech- 
nical content  requirements  for  digital  electronic  equipments  are  almost 
nonexistent. 

The  process  by  which  TM  specifications  are  reviewed,  updated,  and  changed 
by  the  Navy  is  quite  lengthy.  Before  TMs  employing  new  specification  requirements 
reach  the  user,  several  years  may  have  elapsed.  For  this  reason,  the  majority  of 
existing  TM  specifications  describing  technical  content  requirements  are  based  on 
out-of-date  physical  or  psychological  knowledge  with  regard  to  user  information 
needs.  During  Task  1 of  this  effort,  26  Navy  TM  specifications  were  evaluated  for 
requirements  governing  TM  style,  format,  technical  content,  readability,  and  qual- 
ity control.  The  evaluation  showed  these  specifications  were  not  highly  effective 
in  describing  requirements  for  technical  content.  These  same  TM  specifications 
are  used  in  over  90  percent  of  current  Navy  TM  procurements. 

Technical  content  specifications  are  needed  that  are  responsive  to  user 
information  requirements  for  various  system/equipment  types,  (e.g.,  mechanical, 
electrical,  electronic,  hydraulic,  pneumatic)  as  well  as  Navy  operation  and  mainte- 
nance levels  (e.g.,  organizational,  intermediate,  and  depot).  Furthermore,  the  struc- 
ture of  the  specifications  should  be  such  that  they  can  be  easily  modified  to  reflect 
state-of-the-art  equipment  changes.  To  be  responsive  to  these  requirements,  the 
preliminary  system  concept  proposes  a modular  technical  content  specification  struc- 
ture (see  Figure  4-4)  that  provides  specific  technical  content  modules  which  are 
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tailored  to  operation  and  maintenance  requirements  for  each  system/equipment 
type.  Each  module  would  contain  instructions  for  the  content  generators  to  follow 
in  the  development  of  the  type  of  technical  information  required.  Technical  con- 
tent modules  will  be  designed  around  user  information  types  (e.g.,  installation,  func- 
tional descriptions,  corrective  maintenance,  etc.)  and  will  describe  what  is  required 
in  each  information  type  for  different  system/equipment  types  and  different  Navy 
maintenance  levels. 


CONTENT  SPECIFICATION 


INFORMATION  TYPE 


ORIENTATION 


INSTALLATION 


OPE  RATION 


FUNCTIONAL 
DESCRIPT  IONS 
(THEORY  OF 
OPERATION) 


USE  OF  TOOLS 
AND  TEST 
EQUIPMENT 


PREVENTIVE/ 

PLANNED 

MAINTENANCE 


TROUBLE- 

SHOOTING 


CORRECTIVE 

MAINTENANCE 


PARTS- 

IDENTIFICATION/I 
LOCATION 


SYSTEM  DESCRIPTION 
EQUIPMENT  DESCRIPTION 
HOW  TO  USE  TM 
WARNINGS/CAUTIONS/NOTES 


SITE  PREPARATION 
INTERFACE  SPECIFICATIONS 
INSTALLATION  PROCEDURES 
CHECKOUT/QUALIFICATION 


OPERATIONAL  DESCRIPTION 
PREPARATION  AND  PRECAUTIONS 
TURNON  AND  CHECKOUT 

OPERATING  PROCEDURES  (STATIONS.  MODES) 
EMERGENCY  PROCEDURES 


SYSTEM  FUNCTION 
EQUIPMENT  FUNCTION 
PROCESS  DESCRIPTION 
BASIC  CIRCUITS  AND  ASSEMBLIES 


TEST  SETUP 

FUNCTIONAL/PERFORMANCE  TESTS 


INSPECTION 

SERVICE  (CLEAN,  LUBE,  ETC) 
CALIBRATE 

SCHEDULED  PERFORMANCE  CHECKS 


FUNCTIONAL/PERFORMANCE  TESTS 
DEDUCTIVE  TROUBLESHOOTING 
FAULT  ISOLATION  PRINCIPLES 
(AUTOMATED  BITE,  MANUAL) 


ALIGN  AND  ADJUST 
REMOVE  AND  REPLACE 
REASSEMBLE.  ADJUST,  AND  INSPECT 
BENCH  TEST 
REPAIR 


PARTS  LOCATING 
PARTS  IDENTIFICATION 


r 


(12) 


(5) 


(15) 


(10) 


(14) 


(5) 


(20) 


(2) 


(TOTAL;  97  MODULES) 
ORGANIZATIONAL  MAINTENANCE  LEVEL 


(TOTAL  66  MODULES) 
INTERMEDIATE  MAINTENANCE  LEVEL 


(TOTAL  66  MODULES) 
DEPOT  MAINTENANCE  LEVEL 


Figure  4-  4.  Proposed  Technical  Content  Specification  Modules.  Specification  modules  provide  the 
flexibility  to  customize  the  TM  technical  content  specification  to  fit  the  requirements  peculiar  to  a 
specific  system/equipment  type  and  maintenance  level. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4. 1.3.1  DESCRIPTION  OF  TECHNICAL  CONTENT  SPECIFICATIONS  (Continued) 


The  preliminary  system  concept  proposes  97  technical  content  modules  to 
cover  organizational  maintenance  for  all  types  of  systems/equipments  (see  Figure 
4-4).  This  includes  5 modules  covering  operational  information. 

For  intermediate  maintenance,  all  information  types  except  installation  and 
operation  and  portions  of  orientation  are  provided  in  61  modules.  Depot  mainte- 
nance is  also  covered  by  66  modules  tailored  for  depot  requirements.  A total  of 
229  technical  content  modules  are  thus  provided  based  on  preliminary  analysis,  to 
satisfy  the  operation  and  maintenance  technical  content  requirements.  Detailed 
analysis  during  the  NTIP  design  phase  could  yield  some  reduction  in  this  number 
due  to  possible  commonality  in  certain  areas  between  organizational/intermediate 
or  intermediate/depot  information  requirements. 

Providing  individual  modules  allows  the  TM  engineer  in  the  TM  procurement 
function  to  customize  the  technical  content  of  a specific  type  of  manual  (opera- 
tional TM;  organizational,  intermediate,  depot  maintenance  TM;  or  combination 
TM)  to  a specific  system/equipment  and  user  need. 

A hypothetical  set  of  content  modules  for  both  an  organizational  and  depot 
maintenance  manual  is  listed  in  Table  4-1.  A small  electronic  unit  is  assumed, 
such  as  a crypto  device,  which 

• Will  be  repaired  at  the  depot  except  for  fuse  and  power  supply 
replacement. 

• Has  no  operator  function. 

• Requires  periodic  checkout  and  alignment. 

All  modules  listed  are  from  the  electronic  category. 
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TABLE  4-1.  TYPICAL  TECHNICAL  CONTENT  MODULE  SELECTIONS 


Information  Type 

Content  Modules  for 
Organizational  TM 

Content  Modules  for 

Depot  TM 

Orientation 

• Equipment  description 

• Warnings/cautions/notes 

• How  to  use  TM 

• Warnings/cautions/notes 

Installation 

• Installation  procedure 

• Checkout/qualification 

Functional  Description 

• Equipment  function 

• Basic  circuits  and  assemblies 

Use  of  Tools  and  Test 
Equipment 

• Functional/performance 
tests 

• Test  set-up  (bench) 

Preventive/Planned 

Maintenance 

• Scheduled  performance 
checks 

• Inspection 

• Calibrate 

Troubleshooting 

• Fault  isolation  principles 

• Functional/performance  tests 

• Deductive  troubleshooting 

Corrective  Maintenance 

• Remove  and  replace 

• Remove  and  replace 

• Reassemble,  adjust,  and  inspect 

• Bench  test 

• Repair 

Overhaul 

• Inspect  and  repair  as  necessary 
(IRAN) 

• Refurbishment 

Parts  Identification 
Location 

• Parts  Identification 

• Parts  locating 

• Parts  identification 

f 

I 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 


4. 1.3.2  DESCRIPTION  OF  PRESENTATION  TECHNIQUE  SPECIFICATIONS 


The  concept  of  designing  the  TM  by  selecting  particular  presentation  components 
and  systems  in  advance  affords  a method  of  tailoring  the  TM  content  so  that  it  will 
be  highly  compatible  with  specific  user  needs. 

Presentation  specifications  are  needed  at  the  presentation  component  'j 

level,  at  the  combination  level,  and  at  the  presentation  system  level.  Presentation 
components  are  basic  methods  of  organizing  and  conveying  information,  such 
as  types  of  text  discussions,  types  of  diagrams  and  schematics,  methods  of  using 
photographs,  etc.  A presentation  combination  is  a merging  of  the  basic  text  and 
graphic  components  to  meet  a special  user  need,  such  as  understanding  a function, 
troubleshooting  an  equipment,  or  making  an  adjustment.  A presentation  system 
is  unique  in  that  it  organizes  combinations  of  text  and  graphic  components  to  | 

form  a cohesive  TM  presentation  approach.  Examples  of  current  TM  approaches  | 

using  unique  presentation  systems  are  FOMM  and  JPA.  i 

TM  specifications  that  currently  describe  presentation  components,  combina- 
tions, and  systems  are  generally  based  upon  a categorical  approach  to  system  i 

or  equipment  types.  This  "cover  the  world"  approach  does  not  always  best  define  ! 

what  is  really  needed  in  a particular  system/equipment  TM  to  satisfy  its  unique  i 

user's  needs.  Data  requirements  are  constantly  changing  because  equipment  types  i 

that  compose  a system,  the  complexity  of  the  methods  for  implementing  systems,  i 

and  their  functions  are  constantly  changing.  As  a result,  outdated  TM  specifications  ; 

are  being  used  to  design  presentation  techniques  that  are  not  always  compatible 
with  user  requirements  and  system  conditions.  Modular  specifications  could  be 
utilized  to  compensate  for  different  presentation  techniques  that  are  required 
by  constant  state-of-the-art  changes  in  system/equipments.  The  modularity  feature 
makes  for  ease  of  addition  in  keeping  up  with  state-of-the-art  advances  in  present- 
ation techniques. 

The  preliminary  concept  proposes  modules  (see  Table  4-2)  that  would 
accommodate  data  presentation  components,  combinations,  and  systems  that  ' 

now  exist.  These  modules  would  describe  complete  text  and  illustration  requirements  , 

for  a TM  and  provide  instructions  and  examples  for  their  implementation.  The 
presentation  technique  modules  will  be  developed  to  cover  all  categories  of  Navy 
equipment,  including  electronic,  hull,  mechanical,  and  electrical.  Each  module 
will  contain  the  principles  and  rationale  behind  the  presentation  technique  and 
address  the  mechanics  of  structure,  style,  and/or  symbology  in  its  development.  j 

The  table  shows  modules  for  which  presentation  technique  specifications 
would  be  developed.  Specifications  created  within  each  module  will  be  generated  I 

as  self-contained  entities.  These  modules  are  based  on  a preliminary  Hughes  study 
of  basic  presentation  components  and  combinations.  The  preliminary  concept  pro- 
poses 29  basic  presentation  components  and  7 combinations  that  can  be  used  to  i 

organize  TM  data  into  12  presentation  systems. 

When  the  user-data  match  model  is  completely  developed,  new  presentation 
techniques  may  be  identified.  Specifications  for  these  new  techniques  will  be 
generated  by  adding  to  existing  modules  or  creating  a new  module. 

Presentation  technique  modules  would  be  selected,  in  most  cases,  using 
the  techniques  identified  in  the  user-data  match  model.  For  example,  a TM  procure-  | 

ment  may  be  in  process  to  buy  a TM  for  a display  console  for  an  electronic  tech- 
nician (ET)  rating.  The  user-data  match  model  will  identify  the  task  actions  | 
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that  the  rating  (ET)  must  perform  at  the  defined  equipment  level  (system,  compon- 
ent, or  piece  part)  and  the  best  presentation  components  for  his  assigned  tasks. 

The  presentation  systems,  in  this  case,  may  be:  (1)  text  with  supporting  figures, 

(2)  functional  diagrams  with  supporting  text/tables/illustrations,  and  (3)  procedural- 
ized  diagrams  with  supporting  text.  Presentation  technique  modules  would  then 
be  selected  that  give  the  rationale  and  step-by-step  procedures  for  the  development 
of  the  technical  information.  These  modules  would  be  combined  with  modules 
from  other  specification  categories  in  the  design  of  the  complete  TM  specification. 


f AHLE  4-2.  PROPOSED  PRESENTATION  TECHNIQUE  SPECIFICA  flON  MODULES 


Basic  Component  Modules 

Text 

• Deductive  and  narrative 

• Directive,  procedural 


Tables,  Charts,  Matrices 

• Maintenancy  dependency  charts 

• Fault  isolation  flow  charts 

• Periodic  maintenance  tables 

• Troubleshooting  matrices 

• Wire  lists  (manual/ ADP) 

• Parts  lists  (manual/ ADP) 

Diagrams 

• Schematic 

• Connection/wiring/cabling 

• Logic  (single  flow/stick) 

• Mechanical  schematic 

• Piping 

• Block  (functional/detailed/flow) 

• Timing 

• Fluid  power 


Drawings 

• Assembly  (mono/multi) 

• Interface 

• Interface 

• Installation,  outline,  mounting 

• Plan,  elevation 

• Optical  (element/system) 

• Wiring  harness 

• Exploded/assembled/cut  away 
view 

Pictorial  Drawings 

• Cartoons 

• Sketches 


Miscellaneous 

• Photographs 

• Waveform  diagrams 

» Graphs,  plots 


Component  Combination  Modules 

Text  with  supporting  figures,  tables,  or  pictorials 
Modular  text  with  supporting  illustrations 
Text  keyed  to  or  integrated  with  illustrations  or 
diagrams 

Tables/matrices  with  supporting  text/illustrations 

Illustrated  parts  lists 

Dlustrations  with  keyed  procedures 

Diagrams  or  pictorials  with  supporting  captions/text 

procedures 

Presentation  System  Modules 
Job  Performance  Aids  (JPA)  - procedure-keyed/inte- 
grated  diagrams 

Planned  Maintenance  System  (PMS)  - formatted  pro- 
cedures on  cards 

Condensed  Service  Data  (CONSD)  - fault  cues,  data, 
and  diagrams  for  troubleshooting 
Graphic  Operations  Manual  (GOM)  - tables  with  sup- 
porting illustrations 

Maintenance  Data  System  (MDS)  - flow  charts  and  pro- 
cedures with  supporting  illustrations 
Simplified  Operations  Manual  (SOM)  - combined  GOM- 
JPA  and  conventional  approaches 
Binary  Fault  Isolation  Chart  (BFIC)  - digital  computer 
flow  chart 

Functionally  Oriented  Maintenance  Manual  (FOMM)  - 
functional  diagrams  with  integrated  text 
Pyramid  of  Diagrams  (PYRAGRAM)  - modular  dia- 
grams with  supporting  text 

Graphically  Proceduralized  Aids  for  Maintenance 
(GPAM)  - illustrations  with  supporting  text 
Work  Packages  (WP)  - packages  containing  all  data 
necessary  to  accomplish  a functionally  complete 
maintenance  task. 

Sequential  I'hematic  Organization  of  Publications 
(STOP)  - topical  modular  text,  supported  with  thesis 
sentences  and  illustrations 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 


4.1. 3.3  PRELIMINARY  CONCEPT  OF  READABILITY  FOR  NTIPS 


i The  preliminary  concept  on  readability  proposes  methodology  to  both  predict  and  pro- 

duce readable  text.  It  would  be  implemented  by  specifications  using  existing  formulas 
' for  the  prediction  of  readability,  and  by  writers  guides  that  would  aid  the  production 

of  more  readable  text. 

Kincaid,  et  al  (1975),  provides  a concise  review  of  the  need  for  improved 
readability: 

"Studies  conducted  by  all  three  military  services  have  verified  that 
TM  material  that  must  be  comprehended  to  do  the  maintenance 
job  is  written  at  a level  of  difficulty  above  the  reading  ability  of 
the  maintenance  technician  (Kincaid,  1967;  Smith  and  Kincaid,  1970; 

Klare,  1963;  Caylor,  Sticht,  Fox,  and  Ford,  1972;  Carver,  1973;  Duffy 
and  Nugent,  1974).  One  recent  Air  Force  study  (Johnson,  Relova, 
and  Stafford,  1972)  has  traced  many  costly  errors  to  the  reading 
difficulty  level  of  the  instructions  that  are  to  be  followed  in  man- 
uals. The  more  difficult  the  material,  the  more  mistakes  were  made." 

Since  there  is  a high  correlation  between  readability  and  comprehension, 
the  use  of  predictive  formulas  to  aid  in  lowering  the  readability  scores  seems  to 
be  the  most  practical  approach.  Per  Kincaid: 

"Remedial  reading  instruction  would  require  a great  deal  of  effort 
for  significant  gains  in  reading  ability  to  be  achieved.  Similarly, 
selecting  personnel  with  high  reading  abilities  is  getting  progressively 
more  difficult,  both  because  the  average  high  school  graduate  is 
not  reading  as  well  as  ten  years  ago  and  because  of  the  new  all- 
volunteer concept  in  the  military  services.  Carver  (1973)  estimates 
that  the  average  reading  ability  of  Navy  enlisted  personnel  is  about 
the  ninth  grade.  Pinning  (1974)  estimates  this  ability  to  be  10.0 
and  projected  that  it  would  fall  to  9.0  by  the  1979-82  time  frame." 

New  TM  specifications  (e.g.,  MIL-M-38784)  and  guides  currently  under  de- 
velopment by  the  military  services  specify  an  RGL  of  about  nine,  and  utilize  Flesch, 
ARI,  or  versions  of  the  Fog  formula  in  calculating  readability.  The  new  NAVAIR 
writers  guide,  NAVAIR  00-25-700,  requires  RGLs  of  9 to  10  and  specifies  the  use 
of  the  Fog  index  or  Flesch  Reading  Ease  formula  as  tools  for  measurement.  A new 
NAVSEA  TM  specification  under  development  has  an  average  RGL  requirement 
of  9,  and  specifies  the  use  of  Flesch  or  Automated  Readability  Index  (ARI)  formulas, 
recalculated  for  Navy  use,  as  measurement  tools. 

Following  this  lead,  the  preliminary  concept  for  predicting  readability  pro- 
poses the  use  of  the  Flesch  and  ARI  formulas  (see  Table  4-3).  The  Fog  formulas 
would  be  considered  an  alternative,  since  they  may  not  be  interchangeable  with 
Flesch,  yet  might  be  even  more  suitable  to  the  technical  literature  (see  below)  as 
a TM  procurement  specification.  The  Flesch  formula  is  the  most  widely  used  and 
most  heavily  validated  formula.  The  ARI  formula,  having  an  equivalent  mathema- 
tical form,  would  be  expected  to  be  interchangeable  with  Flesch.  ARI  has  the  fur- 
ther advantage  of  being  implementable  by  counters  attached  to  electric  typewriters. 
(Though  such  measurement  methods  would  probably  be  replaced  eventually  by  com- 
puter services  or  the  Contractor's  text  processing  facilities.) 

Based  on  studies  of  sample  TM  material  at  Hughes,  the  Fog  formulas  may 
not  be  interchangeable  with  Kincaid's  new  Flesch  RGL  formula.  The  new  Flesch 
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that  the  rating  (ET)  must  perform  at  the  defined  equipment  level  (system,  compon- 
ent, or  piece  part)  and  the  best  presentation  components  for  his  assigtied  tasks. 

The  presentation  systems,  in  this  case,  may  be:  (1)  text  with  supporting  figures, 

(2)  functional  diagrams  with  supporting  text/tables/illustrations,  and  (3)  procedural- 
ized  diagrams  with  supporting  text.  Presentation  technique  modules  would  then 
be  selected  that  give  the  rationale  and  step-by-step  procedures  for  the  development 
of  the  technical  information.  These  modules  would  be  combined  with  modules 
from  other  specification  categories  in  the  design  of  the  complete  TM  specification. 


I'AHI.E  4-2.  PKOPOSEU  PllESENTATlON  TECHNIQUE  SPECll-'lCA  I'lON  MODULES 


Basic  Component  Modules 


Text 


• Deductive  and  narrative 

• Directive,  procedural 


Tables,  Charts,  Matrices 


Maintenancy  dependency  charts 
Fault  isolation  flow  charts 
Periodic  maintenance  tables 
Troubleshooting  matrices 
Wire  lists  (manual/ADP) 

Parts  lists  (manual/ADP) 


Diagrams 


Schematic 

Connection/wiring/cabling 
Logic  (single  flow/stick) 
Mechanical  schematic 
Piping 

Block  (functional/detailed/flow) 

Timing 

Fluid  power 


Drawings 


Assembly  (mono/multi) 

Interface 

Interface 

Installation,  outline,  mounting 
Plan,  elevation 
Optical  (element/system) 
Wiring  harness 

Exploded/assembled/cut  away 


view 


Pictorial  Drawings 

• Cartoons 

• Sketches 


Miscellaneous 


• Photographs 

• Waveform  diagrams 

• Graphs,  plots 


Component  Combination  Modules 


Text  with  supporting  figures,  tables,  or  pictorials 
Modular  text  with  supporting  illustrations 
Text  keyed  to  or  integrated  with  illustrations  or 
diagrams 

Tables/matrices  with  supporting  text/illustrations 

Illustrated  parts  lists 

Illustrations  with  keyed  procedures 

Diagrams  or  pictorials  with  supporting  captions/text 

procedures 


Presentation  System  Modules 


jays  

Job  Performance  Aids  (JPA)  - procedure-keyed/inte- 
grated  diagrams 


Planned  Maintenance  System  (PMS)  - formatted  pro- 
cedures on  cards 

Condensed  Service  Data  (CONSD)  - fault  cues,  data, 
and  diagrams  for  troubleshooting 
Graphic  Operations  Manual  (GOM)  - tables  with  sup- 
porting illustrations 

Maintenance  Data  System  (MDS)  - flow  charts  and  pro- 
cedures with  supporting  illustrations 
Simplified  Operations  Manual  (SOM)  - combined  GOM- 
JPA  and  conventional  approaches 
Binary  Fault  Isolation  Chart  (BFIC)  - digital  computer 
flow  chart 

Functionally  Oriented  Maintenance  Manual  (FOMM)  - 
functional  diagrams  with  integrated  text 
Pyramid  of  Diagrams  (PYRAGRAM)  - modular  dia- 
grams with  supporting  text 

Graphically  Proceduralized  Aids  for  Maintenance 
(GPAM)  - illustrations  with  supporting  text 
Work  Packages  (WP)  - packages  containing  all  data 
necessary  to  accomplish  a functionally  complete 
maintenance  task. 

Sequential  I'hematic  Organization  of  Publications 
(STOP)  - topical  modular  text,  supported  with  thesis 
sentences  and  illustrations 
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Section  4 --  Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4,1  - TM  Acquisition  Subsystem 

4.1. 3.3  PRELIMINARY  CONCEPT  OF  READABILITY  FOR  NTIPS 

t 

[ The  preliminary  concept  on  readability  proposes  methodology  to  both  predict  and  pro- 

I duee  readable  text.  It  )uld  be  implemented  by  specifications  using  existing  formulas 

[ for  the  prediction  of  readability,  and  by  writers  guides  that  would  aid  the  production 

of  more  readable  text. 

Kincaid,  et  al  (1975),  provides  a concise  review  of  the  need  for  improved 
1 readability; 

"Studies  conducted  by  all  three  military  services  have  verified  that 
TM  material  that  must  be  comprehended  to  do  the  maintenance 
job  is  written  at  a level  of  difficulty  above  the  reading  ability  of 
the  maintenance  technician  (Kincaid,  1967;  Smith  and  Kincaid,  1970; 

Klare,  1963;  Caylor,  Sticht,  Fox,  and  Ford,  1972;  Carver,  1973;  Duffy 
^ and  Nugent,  1974),  One  recent  Air  Force  study  (Johnson,  Relova, 

and  Stafford,  1972)  has  traced  many  costly  errors  to  the  reading 
difficulty  level  of  the  instructions  that  are  to  be  followed  in  man- 
uals. The  more  difficult  the  material,  the  more  mistakes  were  made." 

Since  there  is  a high  correlation  between  readability  and  comprehension, 
the  use  of  predictive  formulas  to  aid  in  lowering  the  readability  scores  seems  to 
be  the  most  practical  approach.  Per  Kincaid: 

"Remedial  reading  instruction  would  require  a great  deal  of  effort 
for  significant  gains  in  reading  ability  to  be  achieved.  Similarly, 
selecting  personnel  with  high  reading  abilities  is  getting  progressively 
more  difficult,  both  because  the  average  high  school  graduate  is 
not  reading  as  well  as  ten  years  ago  and  because  of  the  new  all- 
volunteer  concept  in  the  military  services.  Carver  (1973)  estimates 
that  the  average  reading  ability  of  Navy  enlisted  personnel  is  about 
^ the  ninth  grade.  Pinning  (1974)  estimates  this  ability  to  be  10.0 

and  projected  that  it  would  fall  to  9.0  by  the  1979-82  time  frame." 

New  TM  specifications  (e.g.,  MIL-M-38784)  and  glides  currently  under  de- 
velopment by  the  military  services  specify  an  RGL  of  about  nine,  and  utilize  Flesch, 
ARI,  or  versions  of  the  Fog  formula  in  calculating  readability.  The  new  NAVAIR 
writers  guide,  NAVAIR  00-25-700,  requires  RGLs  of  9 to  10  and  specifies  the  use 
of  the  Fog  index  or  Flesch  Reading  Ease  formula  as  tools  for  measurement.  A new 
NAVSEA  TM  specification  under  development  has  an  average  RGL  requirement 
of  9,  and  specifies  the  use  of  Flesch  or  Automated  Readability  Index  (ARI)  formulas, 
recalculated  for  Navy  use,  as  measurement  tools. 

Following  this  lead,  the  preliminary  concept  for  predicting  readability  pro- 
poses the  use  of  the  Flesch  and  ARI  formulas  (see  Table  4-3).  The  Fog  formulas 
would  be  considered  an  alternative,  since  they  may  not  be  interchangeable  with 
Flesch,  yet  might  be  even  more  suitable  to  the  technical  literature  (see  below)  as 
a TM  procurement  specification.  The  Flesch  formula  is  the  most  widely  used  and 
most  heavily  validated  formula.  The  ARI  formula,  having  an  equivalent  mathema- 
tical form,  would  be  expected  to  be  interchangeable  with  Flesch.  ARI  has  the  fur- 
ther advantage  of  being  implementable  by  counters  attached  to  electric  typewriters. 
(Though  such  measurement  methods  would  probably  be  replaced  eventually  by  com- 
puter services  or  the  Contractor's  text  processing  facilities.) 

Based  on  studies  of  sample  TM  material  at  Hughes,  the  Fog  formulas  may 
not  be  interchangeable  with  Kincaid's  new  Flesch  RGL  formula.  The  new  Flesch 
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formula,  like  its  predecessor,  is  weighted  so  that  is  is  sensitive  to  word  lengh  com- 
oared  to  sentence  length.  It  linearly  penalizes  words  larger  than  three  syllables. 

C the  other  hand,  the  Fog  formulas  ignore  word  lengths  longer  than  three  syllables 
and  are  more  sensitive  to  average  sentence  length.  Thus,  when  the  sample  material 
contains  either  a large  percentage  of  big  words  over  three  syllables  or  short  sen- 
tences, the  measurements  diverge. 

For  example,  a study  of  23  sample  TlVl  paragraphs  at  Hughes  measured  by 
both  the  new  Flesch  RGL  formula  and  the  NAVSEA  Fog  RGL  formula  shows  a diver- 
gence that  ranges  up  to  6.7  grade  levels,  averaging  1.99  RGLs  (48  percent  of  tne 
differences  were  between  2 and  6.9  RGLs).  In  many  cases  the  biggest  difference 
occurs  for  samples  having  a heavy  proportion  of  words  of  more  than  three  syllables 
or  sentences  shorter  than  average  (e.g.,  the  ASL  for  the  paragraph  in  question  is  un- 
der 17  words/sentence,  in  a population  of  paragraphs  having  an  ASL  of  24.6  words/ 
sentence).  Using  NAVAIR's  Fog  formula,  the  disparity  is  even  larger,  averaging  3.23 
RGLs,  where  60  percent  of  the  differences  lie  between  3 and  6.1  RGLs.  This  appeflr^ 
to  be  a significant  obstacle  to  interchangeability.  Interchangeability  is  important  Im'- 
cause  the  concept  of  RGL  as  applied  to  a text  is  understood  in  practice  as  a uni- 
versal standard  of  measurement. 

The  Flesch,  ARI,  and  NAVSEA  Fog  formulas  shown  are  those  recalculated 
specifically  for  Navy  use  (by  Kincaid,  et  al,  1975).  The  formulas  were  L'implified  in 
the  process.  The  recalculated  Flesch  formula  has  different  coefficients  than  the 
original  Flesch  Reading  Ease  Formula  and  is  expressed  directly  in  RGL.  The  ARI 
formula  was  rescaled  to  be  more  compatible  with  the  reading  ability  of  Navy  per- 
sonnel. The  recalculated  NAVSEA  Fog  index  provides  a single  formula  (now  appli- 
cable across  the  entire  readability  range)  and  is  scaled  for  Navy  users. 


TABLE  4-3.  CANDIDATE  READABILITY  FORMULAS 
Original  Flesch: 

• RE  = 206.835  - 1.015  words/sentence  - 84.6  syllables/word 
Proposed  Concept: 

• Flesch  RGL  = 0.4  (words/sentence) +12  (syllables/word) -16 

• ARI  RGL  = 0.4  (words/sentence)  +6  (keystrokes/word)  -27.4 

Alternatives: 

, , feasv  words*  +3  hard  words  **  „ 1 

• fob  (NAVSEA)  RGL  = 0.5  -3j 

• Foe  (NAVAIR)  RGL  = 0.4  j^toSal’ enlfenoei  **  "o'-*  ] 

♦Easy  words  are  1 and  2 syllable  words 
♦♦Hard  words  are  those  having  more  than  2 syllables 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4.1. 3.3  PRELIMINARY  CONCEPT  OF  READABILIl’Y  FOR  NTIPS  (Continued) 


One  reason  the  Fog  formulas  have  become  popular  is  that  they  are  relatively 
easy  to  apply  using  manual  counting  methods.  Perhaps  an  even  more  significant 
reason  for  adopting  them  on  technical  material  would  be  that  they  do  not  penalize 
the  larger  big  words  that  would  be  expected  to  characterize  many  kinds  of  TM  mate- 
rial, but  do  "give  credit"  for  a higher  proportion  of  short  sentences.  TM  material 
being  prepared  to  meet  RGL  standards  may  be  characterized  by  a higher  proportion 
of  short  sentences,  since  the  options  in  eliminating  the  technical  vocabulary  are 
somewhat  limited.  Thus,  the  Fog  formulas  might  provide  a more  comfortable  con- 
tracting standard,  even  though  their  validation  would  fall  into  question  over  the 
larger  big  word  issue.  This  area  is  worthy  of  additional  study.  In  addition,  although 
manual  calculations  are  not  excluded,  the  preliminary  concept  would  promote  the 
computerizing  of  readability  assessments  wherever  possible,  to  gain  consistency 
of  results,  and  Navy  specification  of  the  software  mechanization  to  insure  uniformity 
of  measurement. 

The  promotion  of  computerized  readability  assessments  is  proposed  because 
the  manual  calculation  of  readability  on  sample  texts  leads  to  inconsistent  results. 
Manual  calculations  are  difficult  to  perform  because  of  human  mistakes  in  counting 
syllables,  doing  the  arithmetic,  differing  interpretations  of  the  rules  on  how  to 
handle  abbreviations,  acronyms,  numbers,  hyphenated  words,  semicolons,  etc.  Pre- 
cise instruction  guides  for  manual  calculation  of  readability  formulas  will  be  nec- 
essary, but  they  will  not  assure  uniform  results.  Promoting  the  computerization 
of  the  readability  formulas  would  mitigate  these  problems  and  encourage  more  fre- 
quent sampling.  Most  contractors  in  the  future  will  have  access  to  computer  ser- 
vices, and  the  cost  of  typing  in  the  sample  material  is  negligible. 

However,  Navy  specification  of  the  software  would  be  necessary  for  com- 
puterized readability  assessments,  since  content  generators,  left  to  their  own  de- 
vices, would  mechanize  the  formulas  in  different  ways.  Differing  algorithms  for 
sentence  recognition  and  syllable  recognition  produce  different  RGL  scores  on  the 
same  material.  For  example,  some  Flesch  computerizations  count  semicolons  as 
sentences,  a somewhat  questionable  practice.  One  syllabification  algorithm  (based 
on  counting  nonconsecutive  vowels)  would  identify  "thereby,"  "wavelength,"  "move- 
ment," "elsewhere,"  etc.,  as  3-syllable  words.  Similary,  the  counting  of  hyphenated 
words  as  single  words  (e.g,,  "digital-to-analog,"  "phase-detected,"  "space-stabilized," 
"motor-generator,"  "noise-plus-signal,"  etc.,  is  undoubtedly  an  inflation  of  the  word 
length  penalty.  Developing  the  best  algorithms  for  the  TM  application  and  adjusting 
any  validation  impact  would  require  further  study  and  coordination  between  the 
various  authorities. 

The  Dale-Chall  formula  was  not  selected  for  use  in  NTIPS  since  the  old 
list  of  3,000  familiar  words  is  largely  exclusive  of  technical  terms.  Some  writers 
in  the  education  field  prefer  the  Dale-Chall  formula  because  of  its  reliance  on  a 
difficult  word  list  rather  than  syllable  count.  But  to  apply  the  method  more  speci- 
fically to  the  TM  field  (e.g.,  adding  technical  words  known  by  80  percent  of  Navy 
operation  and  maintenance  personnel),  while  not  unfeasible,  would  undoubtedly  re- 
quire many  disciplinary  sections  and  pose  additional  development  expense.  The 
practicabiliity  of  the  addition  of  specialized  technical  terms  has  not  yet  been  ex- 
plored. Furthermore,  the  Dale-Chall  is  more  difficult  to  compute  manually,  as  con- 
stant look-up  in  the  list  is  required,  and  it  has  not  been  calibrated  for  Navy  use  as 
have  the  Flesch,  Fog,  and  ARI  formulas. 

The  assessment  of  readability  is  not  an  end  in  itself.  Even  more  important 
is  a program  to  educate  TM  writers  on  its  importance  and  on  methods  of  producing 
more  readable  writing  to  begin  with.  A definitive  writers  guide  on  the  subject  of 
both  measuring  and  producing  readable  texts  is  sorely  needed.  Particularly,  the 
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average  TM  writer  needs  to  learn  the  various  distinct  style  mechanisms  at  his  dis- 
posal for  varying  the  RGL  of  a given  passage.  Specific  methods  and  ground  rules 
for  dividing  sentences,  disembedding  clauses,  substituting  words,  deleting  words, 
avoiding  circumlocutions,  etc.,  are  what  is  needed.  This  is  a parametric  discipline 
and  needs  to  be  learned  in  quantitative  terms,  as  well  as  in  terms  of  achieving  clear 
writing  in  the  "old  fashioned"  comprehensibility  sense.  Graphics  readability  is  also 
a concern.  The  NTIPS  readability  concept  would  be  incomplete  without  such  a hand- 
book (see  topic  4.2.8). 

The  future  evolution  of  quantitative  readability  assessment  into  quantitative 
comprehensibility  assessment  must  also  be  accommodated  by  NTIPS.  While  reada- 
bility is  established  as  a good  predictor  of  comprehension,  it  is  not  a good  measure 
of  comprehensibility  in  its  widest  sense  (see  definitions.  Appendix  C).  A more  direct 
approach  to  measuring  comprehensibility,  based  on  such  factors  as  word  familiarity 
and  concreteness,  syntactical  structure,  rhetorical  clarity,  logical  continuity,  etc., 
will  eventually  be  possible  based  on  research  already  completed  or  currently  going  on 
(e.g.,  "Application  of  Structure-of-Intellect  and  Psycholinguistic  Concepts  to  Read- 
ing Comprehensibility  Measurement,"  Siegel,  et  al,  1974).  NTIPS  should  be  prepared 
to  coordinate  and  apply  this  discipline  as  it  matures,  through  its  educational  influ- 
ences over  all  TM  contractors. 


TABLE  4-4.  FEATURES  OF  READABILITY  CONCEPT 

• Use  of  Flesch  and  ARI  readability  formulas 

• Potential  use  of  Fog  formulas  as  alternative 

• Promotion  of  computerized  readability  assessments 

• Navy  specification  of  software  mechanization 

• Preparation  of  writers  guides  for  the  production  of  readable  text 

• Accommodation  of  future  comprehensibility  factors 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4. 1.3.4  CONSIDERATIONS  FOR  SETTING  THE  RGL  REQUIREMENTS 


The  present  trend  in  TM  specifications,  which  sets  all  readability  requirements  at  a 
standard  RGL  of  9,  may  not  be  advisable  from  either  an  economic  or  comprehensibility 
viewpoint.  An  alternative  is  to  adjust  the  required  RGL  according  to  the  distribution 
of  RGL  performance  across  the  ratings,  and  to  differences  in  the  types  of  conceptual 
content  of  the  text. 

The  question  of  how  to  set  the  RGL  requirement  for  TMs  remains  to  be 
addressed.  While  the  trend  seems  to  be  toward  setting  all  TMs  at  the  lowest  con- 
ceivable level,  it  can  be  argued  that  the  RGL  requirement  should  be  matched  more 
equitably  to  the  user  in  each  procurement,  to  reduce  the  economic  penalties,  or 
that  some  compromise  between  cost  and  the  lowest  denominator  be  considered. 

Most  TM  specifications  in  current  use  refer  to  MlL-M-38784  for  readability 
requirements.  The  requirements  of  this  specification  dictate  average  sentence 
lengths  of  17  to  20  words  and  average  word  lengths  of  1.5  to  1.6  syllables.  Depending 
on  how  converted,  these  will  interpret  into  RGLs  of  about  9 to  10.  The  new  NAVAIR 
writers  guide,  NAVAIR  00-25-700,  requires  RGLs  of  8.7  to  1 1,  and  a new  NAVSE A 
specification,  not  yet  released,  specifies  an  average  RGL  of  9 and  a maximum  of 
10.  Thus,  military  services  that  presently  utilize  MlL-M-38784  or  other  contract 
requirements  to  specify  the  RGL  of  TMs  appear  to  be  fixing  on  an  average  RGL 
of  9.  This  trend  is  based  on  studies  (e.g..  Carver,  1973)  which  show  that  the  lowest 
RGL  ability  encountered  in  Navy  technical  personnel  is  about  grade  level  9.  Hence, 
the  assumption  that  all  TMs  should  be  written  for  this  level  could  be  called  the 
"lowest  denominator"  approach. 

The  school  of  thought  that  would  argue  for  a "matched"  method  of  setting 
the  RGL  requirement  would  invoke  the  natural  distribution  of  RGL  performances, 
as  illustrated  in  Figure  4-5.  Basically,  this  figure  plots  23  Navy  ratings 
against  General  Classification  Test  (GCT)  scores.  These  ratings  were  selected  (by 
Anacapa  Sciences)  as  most  relevant  to  the  Navy's  TM  problems.  The  chart  shows 
that  a significant  range  in  RGL  ability  above  9 RGLs  is  predictable  from  a correla- 
tion of  GCT  scores  to  RGL  performance  (per  Duffy;  see  Appendix  E).  The  conversion 
formula,  RGL  = -1.95  +0.2396  (GCT),  was  developed  by  Duffy  at  NPRDC  in  1974). 

As  based  on  Hughes  studies,  this  argument  would  contend  that  the  written 
RGL  of  a TM  text  is  not  independent  of  the  conceptual  nature  of  its  content.  Many 
TMs  (particularly  in  the  electronic  field)  manifest  RGLs  in  the  region  of  17  to  19 
(vs  Biersner's  findings  of  11  to  15  RGLs,  1975),  so  they  are  well  above  the  RGL  of 
the  rating  (13).  If  this  is  true  of  most  ratings,  it  could  be  expected  that  an  economic 
penalty  would  be  associated  with  lowering  RGL  requirements  substantially  below 
that  of  the  natural  GCT  distribution.  In  other  words,  to  drive  a TM  text  from  a 
current-practice  19  RGLs  to  a user-matched  13  RGLs  would  incur  certain  desirable 
reforms  in  writing  practice,  but  driving  it  even  lower  to  a requncd  9 RGLs  would  incur 
more  costly  editing  and  iterative  revising  procedures.  Hence  it  would  be  better  if  a 
particular  matched  RGL  were  invoked  for  each  TM  procurement,  as  determined  by  a 
user-data  matching  procedure. 

A modification  of  the  "matched  level"  approach  would  be  to  lower  the  RGL 
requirement  somewhat  under  the  predicted  RGL  of  each  rating  (by  perhaps  one  or 
two  standard  errors),  thus  insuring  a comfortable  R GL  for  the  rating  in  question, 
but  avoiding  the  full  measure  of  the  economic  per  ity.  On  this  point,  it  should  be 
noted  that  a TM  writer's  style  is  probably  not  infinitely  adjustable  to  changes  in 
some  external  RGL  goal.  His  internalization  of  the  RGL  goal  will  be  limited  by 
either  habit,  or  certain  newly  adopted  stylistic  algorithms,  so  that  the  outcome 
of  any  one  attempt  will  undoubtedly  need  assessment  and  revision,  except  for  the 
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most  trivial  cases  of  conceptual  content  difficulty.  Thus,  as  the  RGL  requirement 
is  lowered,  a progressive  penalty  will  be  incurred  in  terms  of  recalculations,  vocab- 
ulary look-up,  grammatical  transformations,  smoothing  operations,  to  overcome 
"choppiness,"  etc. 

A further  application  of  this  approach  would  permit  the  level  of  specified 
RGL  to  be  adjusted  according  to  the  purposes  of  the  information  content.  For  exam- 
ple, a directive  text  would  be  placed  under  a more  stringent  requirement  than  a 
deductive  or  descriptive  narration  since  it  would  be  less  likely  to  depend  on  a higher 
RGL  to  capture  its  conceptual  "payload."  Thus,  the  hypothesis  is  that  the  most 
difficult  conceptual  material  found  in  a TM  for  a given  Rating  (e.g.,  theory  of  oper- 
ation in  electronics)  would  L e understood  best  at  the  RGL  inherent  in  the  GOT  of 
the  Rating,  even  better  than  at  some  minimally  lower  RGL,  due  to  the  sacrifices 
in  content  incurred  by  overly  severe  lexical  constraints.  However,  other  conceptually 
less  difficult  material  (e.g.,  installation)  would  be  understood  best  at  a correspond- 
ingly lower  RGL.  Such  a constraint  in  setting  the  RGL  requirement,  applied  thought- 
fully for  the  circumstances  of  each  procurement,  has  some  appeal,  considering  tliat 
both  economic  and  comprehensibility  benefits  might  accrue.  Consequently,  a 
matched-adjustable  RGL  approach  is  proposed  as  an  alternative  to  the  fixed  9 RGL 
approach  now  gaining  currency  in  the  Services. 
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Figure  4-5.  Ranking  of  Navy  Ratings  by  GCT  Scores  and  Equivalent  RGL  Scores.  The  fixed-level  9 
RGLs  requirement  ignores  the  natural  distribution  of  GCT  levels  between  the  ratings.  The  matched- 
adjustable  RGL  approach  avoids  the  worst  economic  penalties  in  controlling  the  TM  readability  during 
the  writing  and  editing  processes. 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4. 1.3.5  DESCRIPTION  OF  ACCESS  SPECIFICATIONS 


The  access  specification  modules  will  describe  tailored  entry,  indexing  and  numbering 
schemes  for  a variety  of  TM  types  and  media. 

Poor  accessibility  of  printed  information  is  not  a new  complaint  of  tech- 
nical manual  users.  Stroessler,  et  al  (1957),  reported^  that  most  TM  indexes  were 
nothing  more  than  alphabetized  tables  of  contents.  Most  information  required 
by  the  technician  is  not  easily  obtained  by  using  such  an  index.  The  problem  becomes 
more  difficult  when  a TM  is  placed  on  microform  with  no  additional  thought  given 
to  the  index.  In  this  case,  not  only  can  the  technician  not  find  the  information 
he  needs  by  using  the  index,  but  thumbing  through  the  TM,  as  would  be  done  with 
a conventional  manual,  is  not  possible.  In  addition,  if  TMs  are  placed  on  video 
discs,  location  of  poorly  indexed  information  becomes  a virtual  impossibility. 

To  eliminate  the  difficulty  experienced  in  finding  information  within  TMs, 
the  access  specification  category  will  provide  modules  which  will  define  the  access- 
ibility requirements  and  recommended  access  methods  to  be  used  for  various  media. 
The  problem  is  addressed  in  terms  of  access  to  a series  of  technical  manuals,  to 
a single  technical  manual,  and  to  a paragraph  or  subparagraph  level  of  a technical 
manual.  Use  of  the  term  "access'  refers  to  all  these  considerations. 

The  preliminary  system  concept  consists  of  four  specification  modules  (see 
Table  4-5)  that  will  define  access  requirements  which  may  be  utilized  for  TMs 
to  be  developed  in  the  following  media:  bound  paper  documents,  unbound  paper 
documents,  roll  microfilm,  and  microfiche.  Each  access  module  will  provide  require- 
ments for  partitioning,  numbering,  and  indexing  of  TM  information.  Each  access 
module  will  also  contain  practical  tests  and  standards  of  accessibility  similar  to 
those  described  in  NAVAIR  00-25-700. 

The  access  modules  will  contain  methods  to  be  employed  by  content  generators 
in  developing  or  implementing  the  specification  requirements.  For  example,  the 
access  module  for  the  methods  of  indexing  by  subject  for  the  bound  paper  document 
will  contain  requirements  for  the  grouping  of  subjects  that  depend  upon  the  type 
of  TM  or  the  user  application  of  the  TM.  Operator  manuals  may  have  subject  indexes 
arranged  by  modes  of  operation,  and  maintenance  manuals  may  have  subject  indexes 
arranged  by  fault  symptons.  Where  operation  and  maintenance  are  covered  in  diff- 
erent chapters  of  the  same  TM,  different  subject  indexes  would  be  specified  for 
each  chapter. 

Access  techniques  that  have  been  used  widely  in  the  private  and  commercial 
sectors  are  also  useful  for  military  application.  For  example,  requirements  for 
thumb  indexes,  which  are  often  found  in  dictionaries  and  Bibles,  would  be  included 
in  the  NTIPS  specifications.  Access  modules  will  include  many  of  the  traditional 
solutions  as  well  as  requirements  for  additional  approaches  such  as:  leaf-through 
locators,  block  or  colored  boxes  placed  at  the  page  edge,  colored  or  oversized 
pages  in  front  of  each  section,  colored  stock,  simplified  contents  listed  on  cover, 
(cover  page  edge  box),  indented  thumb  indexes,  and  pictorial  and  keyword  indexes. 

Pictorial  and  keyword  indexes  are  other  methods  that  have  been  studied 
for  application  to  military  TMs.  For  example,  the  location  of  maintenance  and 
operating  procedures  or  various  equipment  descriptions  could  be  graphically 


Stroessler,  J.H.,  Clark,  J.M.,  Martin,  P.A.,  and  Grimm,  F.T.,  Human  Factors  in 
the  Design  and  Utilization  of  Electronics  Maintenance  Information,  Research 
Report  No.  782;  31  May  1957;  U.S.  Navy  Electronics  Laboratory  (BUSHIPS), 
San  Diego,  CA. 
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portrayed  on  exploded  views  of  the  equipment.  Keyword  indexes  could  be  utilized 
for  rapid  access  and  retrieval  of  situation-specific  TM  information.  These  Keywords 
could  be  flagged  by  TM  writers  as  the  TM  is  developed  or  collected  automatically 
if  automated  text  processing  machines  are  used  in  the  production  process.  Equip- 
ment nomenclature  and  vocabulary  specifications  for  the  system/equipment  would 
control  the  volume  and  types  of  keywords  used. 


TABLE  4-5.  PROPOSED  TM  ACCESS  SPECIFICATION  MODULES 


Specification 

Requirements  and 
Descriptions 

Bound  Paper 
Documents 
Module 

Unbound  Paper 
Documents 
Module 

Roll 

Microfilm 

Module 

Microfiche 

Module 

Methods  of  Partitioning 

• Volumes 

/ 

/ 

/ 

/ 

• Parts 

✓ 

/ 

/ 

/ 

• Chapters 

/ 

/ 

/ 

/ 

• Sections 

/ 

/ 

/ 

/ 

• Topics 

/ 

/ 

/ 

/ 

• Work  units 

/ 

/ 

— 

- 

Methods  of  Indexing 

• Subject 

/ 

/ 

/ 

/ 

• Paragraph  headings 

/ 

/ 

/ 

/ 

• Illustration  lists  • 

/ 

/ 

/ 

/ 

• Tables  lists 

/ 

/ 

/ 

/ 

• Pictorials 

/ 

/ 

/ 

/ 

• Keywords 

/ 

/ 

/ 

/ 

• Indented  thumb 

/ 

- 

- 

• Colored  stock 

/ 

- 

/ 

• Cover  page  edge  box 

|-  / 

- 

- 

Methods  of  Numbering  and 

i 

Pagination 

• Chapters 

/ 

/ 

/ 

/ 

• Sections 

/ 

/ 

/ 

/ 

• Paragraphs 

/ 

/ 

/ 

/ 

• Roll  leader 

- 

1 

- 

✓ 

• Readable  header 

- 

- 

/ 

- 

• Illustrations 

. / 

/ 

/ 

/ 

• Tables 

/ 

/ 

/ 

Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4,1  - TM  Acquisition  Subsystem 

4.1. 3.6  DESCRIPTION  OF  PUBLISHING  PROCESSES  SPECIFICATIONS 


New  detailed  publishing  process  specifications  are  required  for  the  various  media 
presently  in  use  and  for  those  contemplated  for  the  future.  The  preliminary  concept 
provides  a family  of  specification  modules  to  define  each  of  the  factors  involved  in 
the  publishing  processes  required  to  support  all  contemplated  media. 

The  evolution  from  paper  to  microforms  and  digital  publishing  and  presen- 
tation must  be  supported  by  specifications  concerning  the  new  publishing  processes. 
The  publishing  process  subfunction  would  provide  specifications  that  address  multi- 
media  presentation,  including  digital  methods,  for  TM  production,  transmission  and 
usage. 

The  Publishing  Subsystem  preliminary  concept  proposes  an  automated  in- 
ternal Navy  capability  for  text  and  graphic  input,  edit,  update,  and  output.  The 
publishing  processes  specifications  must  accommodate  these  digital  methods  of 
publishing.  If  the  contractor  is  required  to  deliver  input  to  the  publishing  opera- 
tion that  needs  to  be  entered  into  an  automated  system  and  reprocessed  to  a spe- 
cified output  medium  master,  then  the  medium  for  submittal  of  that  contractor- 
generated  material  must  be  specified.  If  it  is  digital  then,  at  least  the  form, 
language,  and  codes  must  be  specified.  If  it  is  other  than  digital,  at  least  its  form 
must  be  specified.  Table  4-6  lists  the  processing  factors  that  impact  text  and 
graphic  pages  for  different  media.  Media  that  would  be  used  to  deliver  TMs  in  digi- 
tal form  are  included  since  use  of  digital  media  is  considered  possible  in  the  1980-85 
time  frame. 

The  preliminary  concept  for  TM  publishing  process  specifications  are  modu- 
lar specifications  that  would  support  a multi-media  presentation.  Analysis  to  date 
of  both  media  and  processing  factors  indicates  that  a complement  of  35  modules 
could  be  used  to  specify  all  TM  publishing  process  requirements.  The  modular  as- 
pect of  these  specifications  would  help  TM  acquisition  activities  to  define  a com- 
plete spectrum  of  publishing  processes  for  a variety  of  media  that  could  be  easily 
included  in  custom-tailored  TM  specifications.  TM  specifications  must  be 
able  to  deal  with  images  (pages)  that  are  captured  in  one  medium,  transmitted  in 
another,  and  used  in  a third.  For  example,  the  text  and  art  could  be  produced  in 
digital  form,  transmitted  on  a video  disc,  and  viewed  on  display  device  (use  No.  1) 
or  replicated  on  paper  for  use  in  a remote  area  (use  No.  2).  It  would  have  to  be 
specified  that  a video  disc  presentation  on  a TV  screen  must  use  large  type  (at  least 
18  point)  as  compared  to  the  smaller  (10  point)  type  used  on  printed  pages. 

Specification  development  must  be  responsive  to  the  media  requirements 
of  the  system  concept,  namely  paper  and  microforms.  Information  about  new 
media  being  developed  will  also  impact  publishing  process  specifications,  and  must 
be  accommodated.  However,  the  specification  content  is  only  partly  dependent 
upon  the  selection  of  a medium.  A significant  element  of  the  specification  would 
be  the  mechanical  (format)  structure  of  the  page  of  text  or  artwork  (graphic). 

What  goes  where,  how  big  or  small,  what  type  style,  etc.,  make  up  most  of  the 
specific  items  in  the  publishing  process  requirements.  Thus,  since  the  TM  is  con- 
structed with  pages  in  text,  tables,  and  graphics  arranged  in  books  with  sections, 
chapters,  etc.,  regardless  of  the  medium  used  to  deliver  it  (or  use  it),  the  format 
of  the  product  is  the  key  element  to  consider  in  process  operations. 
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TABLE  4-6.  PROPOSED  PUBLISHING  PROCESS  SPECIFICATION  MODULES 


Media 

Processing 

Factors 

Microform 

Digital/Optical 

Paper 

Microfilm 
(Cartridge 
or  roll) 

Microfiche 

1 

Hologram 

Video  Disc 

Direct 

Text  Pages 

Page  size 

Image  area 

(D* 

\ 

X 

(2) 

\ 

X 

(3) 

.r 

\ 

X 

(4) 

X 

(5) 

< 

X 

(6) 

X 

X 

Type  sizes 

Type  faces 

Margins 

Gutters 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Indentions 

X 

X 

X 

X 

X 

X 

Marginal  copy 
Classification  markines 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Illustrations 

(7) 

(8) 

(9) 

(10 

(11) 

(12) 

Image  area 

Symbol  type 

Symbol  size 

Call-outs 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Classification  markines 

X 

X 

X 

X 

X 

X 

Production 

(13) 

(14) 

(15) 

(16) 

(17) 

(18) 

Front  matter 

X 

X 

X 

X 

X 

X 

Text  and  art  integration 
Foldout  pages 

Blank  pages 

Camera  ready  copy 
Splices 

Leaders/trailers/ 
title  strips 

Image  resolution 
Background  density 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Use  of  Color 

(19) 

(20) 

(21) 

(22) 

X 

X 

X 

- 

X 

- 

Packaging 

Negatives 

Repro 

Cartridges 

Disc 

(23) 

X 

X 

(24) 

X 

X 

X 

(25) 

X 

X 

(26) 

X 

(27) 

X 

- 

Replication 

Paper  stock 

Binding 

Photolitho  negatives 
Covers 

(28) 

X 

X 

X 

X 

(29) 

(30) 

(31) 

(32) 

i 

- 

Material  grades/types 
(for  original) 

Material  grades/types 
(for  copies) 

- 

X 

X 

X 

X 

X 

X 

X 

X 

— 

Digital  Media 

Code 

. 

(33) 

X 

(34) 

X 

(35) 

X 

File  structure 

- 

- 

- 

X 

X 

X 

Storage  density 

Storage  format 

- 

- 

- 

X 

X 

X 

X 

X 

X 

♦Specification  module  number 


4-25 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4. 1.3.7  DESCRIPTION  OF  QUALITY  CONTROL  SPECIFICATIONS 


The  preliminary  concept  for  TM  quality  control  specifications  involves  requirements 
for  monitoring  the  TM  inspection  process  of  the  contractors,  and  includes  requirements 
for  a higher  concentration  of  quality  control  efforts  during  the  earlier  phases  of  TM 
development. 

Current  quality  control  specification  requirements  emphasize  post  hoc  TM 
quality  assurance  (i.e.,  during  the  validation  and  verification  phases).  Thus,  serious 
TM  deficiencies  are  ohen  discovered  too  late  to  be  properly  corrected.  Present 
requirements  for  QA  reviews  of  TMs  call  for  the  first  review  after  the  writer  has 
completed  his  first  draft.  At  this  point,  schedule  and  funding  limitations  often  re- 
strict proper  correction  of  deficiencies,  and  the  TMs  are  often  accepted  without 
being  corrected.  A redistribution  of  TM  QA  efforts  and  a redefinition  of  Navy  and 
contractor  responsibilities  are  needed. 

The  current  Navy  TM  QA  requirements,  while  basically  sound  in  intent  and 
purpose,  are  not  completely  manageable.  The  Navy  does  not  have  the  resources 
to  fully  audit  the  total  TM  products  from  all  its  contractors.  The  NTIPS  quality 
specifications  concept  redefines  and  redistributes  the  current  QA  efforts,  both  by 
the  Navy  and  by  the  contractor.  NTIPS  QA  personnel  will  be  required  to  audit  the 
contractor  QA  personnel,  who  in  turn,  will  be  required  to  monitor  the  TM  develop- 
ment process.  In  addition,  while  past  TM  QA  has  concentrated  80  percent  of  the 
effort  in  the  final  phases  of  the  TM  development  process,  the  proposed  concept 
shifts  this  effort  to  the  early  phases.  This  approach  for  data  base  and  content  gen- 
eration was  recommended  by  Hageman  Consulting  Services^  in  conjunction  with 
the  NTIP  Program.  The  resulting  QA  specification  modules,  together  with  the  QA 
provision  for  publishing  and  distribution,  are  contained  in  three  groups  totaling  12 
QA  modules  (see  Table  4-7). 

Data  Base  Generation  - TM  quality  assurance  programs  generally  provide 
for  little  or  no  activity  during  data  base  generation.  Some  QA  plans  provide  for 
the  necessary  auditing  of  bookplans  to  assure  compliance  with  contract  specifica- 
tions. A much  greater  emphasis  on  quality  assurance  during  data  base  generation 
is  required.  In  addition  to  assuring  that  content  generators  have  the  requirements 
and  guidance  data  to  comply  with  specified  formats  and  styles,  it  is  also  essential 
that  QA  audits  the  data  accumulated  during  the  early  phases  of  TM  preparation, 
to  assure  its  accuracy  and  timeliness. 

All  contractual  materials  such  as  statements  of  work  and  quoted  specifi- 
cations should  be  reviewed  by  QA  to  assemble  a checklist  of  the  imposed  TM  re- 
quirements. The  next  level  of  TM  documentation,  those  items  that  provide  guid- 
ance to  content  generators,  writers  and  illustrators,  also  needs  to  be  audited  by  QA. 
This  includes  style  manuals,  writers  guides,  illustrators  guides,  preferred  word  lists, 
etc.,  composed  by  government  agencies  or  by  the  contractor.  Again,  checklists 
are  generated  by  QA  from  the  guidance  requirements  to  augment  the  checklist  mode 
during  the  review  of  contractual  requirements. 

Finally,  QA  makes  spot  checks  of  the  long  list  of  engineering/logistics  data 
base  items  required  by  the  content  generator  to  produce  the  TM.  This  includes  the 
schedule  of  availability  for  these  items  as  established  by  the  TM  engineer  in  the 
estimating  phase  of  the  effort.  Examples  of  these  data  items  include  task  analysis 
and  maintenance  concept  data,  engineering  reports,  engineering  change  proposals 
(ECPs)  and  procurement  test  specifications. 


^Hageman  Consulting  Services;  Quality  Assurance  Program  for  Technical  Documen- 
tation; 1977,  Fort  Worth,  TX. 
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TM  Content  Generation  - Current  TM  QA  requirements  generally  stress 
post  hoc  TM  quality  assurance  in  the  form  of  reviewing  completed  drafts  and  wit- 
nessing validations  and  verifications.  In  the  NTIP  preliminary  system  concept,  the 
TM  Content  Generation  QA  mandates  establishment  of  a QA  program  conducted 
by  the  content  generator's  QA  team.  In  turn,  the  Management  Subsystem  QA  function 
monitors  the  program  by  in-process  reviews,  in  frequency  and  depth  commensurate 
with  program  size. 

Publishing  - As  with  content  generation,  present  publishing  quality  assur- 
ance requirements  are  limited  to  inspecting  the  finished  product.  (For  example, 
in  the  case  of  printed  books,  inspection  includes  checks  of  completeness,  proper 
margins,  legibility,  etc.)  In  the  preliminary  concept,  the  TM  publishing  QA  specifi- 
cation mandates  that  a QA  program  be  established  within  the  Publishing  Subsystem 
and  monitored  by  the  Management  Subsystem  QA  function.  The  needs  and  types 
of  inspection  will  vary  depending  on  the  product  medium,  but  will  include  format, 
completeness,  legibility  and/or  clarity  of  audio  (as  applicable),  and  proper  distribution 
techniques. 


TABLE  4-7.  PROPOSED  QUALITY  CONTROL  SPECIFICATION  MODULES 


Requirements  Group 

Module 

Data  Base  Generation 

1 

• Requirements  and  guidance  data 
(availability  of  style  guides,  pre- 
ferred word  lists,  etc.) 

• Product  (bookplan)  compliance  audit 

• Engineering/logistics  data  (avail- 
ability of  engineering  report,  test 
specifications,  task  analysis,  etc.) 

Content  Generation 

1 

• Input  data  utilization  (use  of  require- 
ments and  guidance  data,  use  of 
correct  engineering  data,  and  exten- 
sion of  requirements  to  subcontrac- 
tors) 

• Inspection  records 

• In-process  reviews 

• Preliminary  and  final  validation 

' • Verification 

Publishing 

• Paper 

• Microform 

• Audio/visual 

• Distribution 

4-27 


Section  4 - Preliminary  System  Concepts  and  Alternatives 
Subsection  4.1  - TM  Acquisition  Subsystem 

4.1.4  DESCRIPTION  OF  THE  TM  PROCUREMENT  FUNCTION 


The  preliminary  concept  for  TM  procurement  is  a decentralized  function  within  the 
NTIPS  organization  dedicated  to  each  major  acquisition  activity.  The  function  would 
be  controlled  by  a "Navy  TM  engineer"  and  have  a funding  structure  that  would  prevent 
TM  procurement  funds  from  being  encroached  upon  by  hardware  acquisition  activities. 

Presently,  TM  acquisition  is  usually  part  of  the  overall  responsibility  of 
the  system  acquisition  project  office.  The  project  office  largely  determines  types 
and  quantities  of  TMs  procured,  and  TM  budgets,  often  without  the  help  of  TM 
specialists.  The  quality  and  quantity  of  TMs  procured  are  related  to  funding  pri- 
orities as  established  (and  re-established)  by  the  hardware  project.  This  results 
in  a great  diversity  in  TM  procurement.  For  example,  the  money  and  manpower 
allocated  for  the  procurement  of  TMs  is  dependent,  in  many  cases,  on  how  critical 
the  particular  hardware  project  office  views  the  TMs  to  be  to  system/equipments 
success.  Furthermore,  those  responsible  for  TM  procurement  do  not  always  under- 
stand fully  the  importance  of  TMs  to  the  ultimate  user.  In  addition,  system  acqui- 
sition project  offices  are  liable  to  be  guarded  in  earmarking  sufficient  funds  for 
TMs  when  they  continually,  over  the  years,  hear  the  same  problem  stories  about 
TMs.  This  may  lead  some  of  them  to  believe  they  are  going  to  get  the  same  in- 
adequate TMs  whether  they  allocate  large  or  small  amounts  of  money.  Consequent- 
ly, preserving  more  of  the  money  for  hardware  becomes  their  goal  and  TMs  receive 
less  funding  and  importance  in  their  minds. 

The  approach  envisioned  for  NTIPS  is  one  of  shifting  of  responsibility  and 
funding  for  TM  procurement  from  the  hardware  project  office  to  the  NTIP  TM 
procurement  function.  Funds  would  be  channeled  to  the  TM  procurement  function 
through  the  NTIP  Management  Subsystem.  The  procurement  of  TMs  and  budgeting 
of  funds  by  a single,  responsible  expert  activity  should  eliminate  the  problem  of 
inconsistent  requirements,  and  inappropriate  funding  priorities,  and  improve  the 
resulting  TM  product. 

The  preliminary  concept  calls  for  a "Navy  TM  engineer,"  a counterpart 
to  the  contractor's  TM  engineer,  to  oversee  and/or  participate  in  the  activities 
required  for  TM  procurement.  The  Navy  TM  engineer  would  be  a TM  and  quality 
assurance  specialist  who  would  ensure  that  TM  objectives  formalized  by  better  TM 
specifications  are  being  realized.  He  would  also  disperse  "captured  funds"  for  the 
initial  procurement  and  update  of  TMs.  These  funds  would  be  preserved  for  their 
original  intent  and  purpose  and  would  not  revert  to  hardware  acquisition,  or  be 
diverted  to  other  logistic  support  activities. 

The  major  responsibilities  of  the  TM  procurement  function  are:  (1)  devel- 
opment of  TM  requirements  documents  for  proposals  and  subsequent  contracts, 

(2)  delivery  scheduling,  (3)  determining  distribution  requirements,  (4)  product 
quality  assurance,  (5)  budgeting  and  funding,  and  (6)  contract  administration.  The 
TM  procurement  function  would  be  staffed  by  a number  of  TM  engineers,  depend- 
ing on  the  size  of  the  major  acquisition  activity  and  the  volume  of  systems/ 
equipments  for  which  TMs  are  required. 

Organizational  Alternatives  - The  preliminary  concept  is  to  have  several 
TM  procurement  functions,  organizationally  a part  of  NTIPS,  each  dedicated  to 
a major  acquisition  activity.  Each  function  (see  Figure  4-6)  would  be  responsible 
for  all  matters  relating  to  the  respective  major  acquisition  activity's  TM  procure- 
ments. One  alternative  consists  of  a centralized  function  that  has  responsibility 
over  all  TM  procurements  for  all  Navy  major  acquisition  activities.  A second  al- 
ternative consists  of  having  a separate  TM  procurement  function  for  each  major 
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acquisition  activity  and  placing  the  function  within  the  organizational  structure  of 
that  activity,  external  to  the  NTIP  System,  but  governed  by  policies  and  procedures 
from  NTIPS. 
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Figure  4-6.  TM  Procurement  Function  Organizational  Alternatives.  The  TM  procurement  function 
will  be  centralized  or  decentralized  within  the  organizational  structure  of  NTIPS,  responding  to  the 
needs  of  each  major  acquisition  activity;  or  it  will  be  a decentralized  function  within  each  major 
acquisition  activity  guided  by  policies  and  procedures  from  NTIPS. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  - Content  Generation  Subsystem 

4.2.1  DESCRIPTION  OF  CONTENT  GENERATION  SUBSYSTEM 


The  Content  Generation  Subsystem  estimates,  plans,  and  develops  technical  information  | 

in  response  to  the  TM  acquisition  requirements.  The  main  challenge  is  to  create  tech-  1 

nical  data  that  is  free  from  content  generator  inaccuracies  and  is  adequate  for  specific  1 

user  needs.  j 

The  Content  Generation  Subsystem  is  critical  in  that  it  represents  the  most  ; 

significant  and  final  point  of  impact  on  technical  information  quality.  The  content  -! 

generator  is  responsible  for  collecting  the  data,  estimating  the  proposed  TM  acquisi- 
tion cost,  preparing  technical  publications  planning  documents,  writing  the  TM,  i 

critiquing  the  TM,  and  performing  validation.  Guided  by  the  data  acquisition  rules,  ! 

the  content  generator  performs  the  human  transformation  of  the  engineering/ 
manufacturing  data  base  into  technical  information.  As  a result  of  human  involve- 
ment, the  transformation  output  is  subject  to  interpretations,  biases,  inadequacies, 
and  errors. 

The  engineering/manufacturing  data  base  is  critical  to  the  content  generator 
because  it  is  the  sole  source  of  system/equipment  descriptions.  The  major  problems 
associated  with  the  data  base  are  limited  content  (e.g.,  no  maintenance  data),  ac- 
curacy, and  currency.  The  preliminary  concept  would  solve  these  problems  by  mod- 
ifying ttie  data  base  content  requirements  to  add  maintenance  data,  and  employ 
automated  equipment  to  eliminate  the  time-consuming  and  error-prone  manual 
methods  for  developing,  checking,  reproducing,  and  distributing  the  data  base. 

The  Content  Generation  Subsystem  preliminary  concept  (Figure  4-7)  would 
consist  of  three  functions  (estimating,  planning  and  writing)  for  developing  new 
and  updated  TMs.  Each  function  contains  techniques  which  are  specifically  designed 
to  reduce  errors  in  the  process  of  transforming  the  engineering/manufacturing  data 
base  into  technical  information.  The  functions  apply  to  both  Navy  in-house  and 
contractor  content  generation  activities.  In  addition,  the  preliminary  concept  would 
establish  a TM  engineering  position  which  impacts  all  tasks  of  each  function.  The 
TM  engineer  provides  for  proper  planning  and  technical  guidance  throughout  the 
TM  program.  He  is  responsible  for  collecting  the  data,  developing  the  TM  estimate, 
preparing  a detailed  TM  book  plan,  writing  the  TM,  technically  critiquing  the  TM, 
and  performing  validation.  He  is  also  responsible  for  a cross  fertilization  between 
the  writers  and  instructors,  as  well  as  ensuring  that  the  engineering/manufacturing 
and  logistic  data  base  information  is  available.  He  confirms  the  optimum  presen- 
tation methods  identified  by  the  user-data  match  model,  he  allocates  writer  tasks, 
and  he  ensures  content  quality.  The  TM  engineer  also  establishes  interrelationships 
with  the  design  engineering  activity  and  the  ILS  elements  to  ensure  coordinated 
efforts  in  TM  development. 

To  aid  the  TM  engineer  in  performing  his  tasks,  detailed  guidance  in  the 
form  of  a TM  Development  Guide  would  be  provided  as  part  of  the  preliminary  con- 
cept. This  guide  provides  step-by-step  instructions  for  the  development  of  TM  esti- 
mates and  planning  documents  as  well  as  for  coordinating  and  supervising  the  actual 
TM  development.  Possible  problem  areas  are  identified  and  solutions  presented 
to  effectively  reduce  the  number  of  difficulties  that  the  TM  engineer  encounters 
in  a TVl  acquisition  program.  This  guide  also  encourages  the  TM  engineer  to  seek 
out  and  apply  innovative  TM  development  and  presentation  techniques  to  meet  tech- 
nological advances  in  system/equipment  design.  The  TM  Development  Guide  is  dis- 
cussed in  detail  in  Topic  4.2.7. 

In  the  preliminary  concept,  provisions  are  made  to  institute  and  maintain 
a quality  assurance  program  as  an  integral  part  of  the  technical  information  devel- 
opment process.  This  would  assure  that  TM  requirements  are  met  during  technical 
information  development  and  validation. 
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Estimating  Function  - An  estimate  is  developed  for  each  TM  preparation 
effort  based  on  the  results  of  the  analysis  of  the  TM  requirements  and  system/ 
equipment  design  information.  The  estimate  provides  the  TM  Acquisition  Subsystem 
with  a detailed  description  of  the  cost  and  effort  that  would  be  incurred  for  the 
proposed  TM.  Detailed  cost  data  includes  such  items  as  labor,  management,  mate- 
rial, overhead,  and  profit  where  the  content  generator  is  a contractor.  Included 
in  the  estimate  is  a detailed  description  of  the  effort  such  as  text  and  illustration 
page  counts  for  the  paper  medium. 

As  part  of  the  effort  to  improve  the  quality  and  sufficiency  of  the  overall 
support  program,  the  technical  information  estimate  development  effort  would  be 
coordinated  witli  the  estimating  efforts  of  the  other  ILS  activities  (such  us  training, 
provisioning,  and  maintenance  engineering).  This  reduces  or  eliminates  redundancies 
among  the  ILS  activities  and  improves  the  total  support  package  supplied  to  the 
using  activities. 

Planning  Function-  The  planning  function,  which  encompasses  the  content 
generator's  total  planning  effort,  is  divided  into  its  basic  subfunctions,  product 
planning  and  operational  planning.  Product  planning  deals  exclusively  with  those 
tasks  related  to  the  development  of  accurate  and  detailed  TM  bookplans  and  out- 
lines. Operational  planning  covers  those  tasks  related  to  the  actual  technical  data 
development:  applying  the  content  generator's  capabilities  in  the  most  efficient 
manner  to  prepare  accurate  and  adequate  technical  data. 

In  the  product  planning  subfunction,  the  problem  of  vague  and  incomplete 
TM  bookplans  and  outlines  based  on  traditional  generalized  specifications  is  over- 
come. Detailed  TM  bookplans  and  outlines  which  accurately  describe  the  TM  to 
be  developed  are  prepared  from  system/equipment  descriptions  in  accordance  with 
the  detailed  requirements  contained  in  the  modular  specifications.  The  product 
planning  is  also  coordinated  with  the  planning  efforts  of  the  other  ILS  elements 
(e.g.,  training,  logistic  analysis,  spare  provisioning)  to  ensure  a totally  integrated 
support  package  is  being  provided  to  the  user. 

Operational  planning  includes  development  of  writing  schedules  and  mile- 
stones, preparation  of  preliminary  validation  and  verification  plans,  and  establish- 
ment of  coordination  with  the  content  generation  support  activities  (text  processing, 
graphics,  production).  Improved  writer  accuracy  and  efficiency  is  ensured  through 
the  preparation  of  writer  work  packages  based  on  the  detailed  bookplan  and  outlines 
and  the  establishment  of  a match  between  the  writer's  capabilities  and  the  work 
package  requirements.  Plans  for  additional  training  are  formulated  where  it  is  indi- 
cated that  the  writer's  capabilities  are  limited. 

Writing  Function  - The  content  generator  prepares  the  technical  informa- 
tion in  accordmice  with  the  directives  and  instructions  developed  in  the  planning 
function.  Any  writer  training  plans,  prepared  during  operational  planning,  are  im- 
plemented to  upgrade  the  writing  staff's  capabilities.  In  the  traditional  writing 
effort,  conflicting  comments  that  result  from  independent  TM  manuscript  reviews 
by  the  TM  acquisition,  design  engineering,  and  training  activities  cause  severe  prob- 
lems. Resolving  these  problems  can  have  serious  adverse  impact  on  the  TM  accuracy 
and/or  adequacy.  This  is  rectified  in  the  preliminary  concept  by  performing  a con- 
current review  and  validation,  with  all  these  activities  and  the  user  activity  partici- 
pating. Quality  assurance  personnel  monitor  the  progress  of  the  writing  effort, 
review  writer  draft  material,  and  generate  and  submit  progress  reports  of  the  TM 
Acquisition  Subsystem.  Included  in  these  reports  are  the  technical  information  de- 
velopment problems  that  have  been  encountered  and  their  solutions.  Direct  Navy 
participation  in  contractor  writing  efforts  consists  of  performing  in-process  reviews 
(IPRs)  of  writer  draft  TM  material  and  participating  in  the  concurrent  TM  manu- 
script review  and  validation  performed  by  the  contractor. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  - Content  Generation  Subsystem 

4.2.2  DESCRIPTION  OF  ENGINEERING/MANUFACTURING  DATA  BASE 


By  adding  maintenance  information  and  applying  automation  technology  to  the 
engineering/manufacturing  data  base,  it  can  be  made  more  accessible  and  beneficial 
to  the  content  generator. 

The  engineering/manufacturing  data  base  is  a critical  input  to  the  content 
generator,  because  it  .s  the  sole  source  of  the  system/equipment  description.  This 
data  base  is  used  by  the  content  gefierator  to  develop  technical  information  cost 
estimates  and  program  planning  documents  (TM  boo. .plans/outlines).  Additionally, 
the  writing  task  consists  largely  of  a transformation  of  the  technical  data  contain- 
ed in  the  data  base  into  technical  information. 

At  present,  the  engineering/manufacturing  data  base  consists  of  engineer- 
ing drawings,  test  specifications,  wire  lists,  parts  lists,  engineering  reports,  design 
notebooks,  memos  and  other  documentation  that  is  required  to  design  and  manu- 
facture a specific  product.  This  data  base  is  developed  by  the  engineering  activity 
for  delivery  to  the  system  procuring  agency  and/or  for  internal  manufacturing  use. 
The  engineering/manufaeturing  data  base  is  developed  to  disclose  the  engineering 
design  concept  for  evaluation,  demonstrate  the  suitability  of  the  engineering  de- 
sign approach  to  support  manufacture  of  a production  prototype,  and  provide  a suf- 
ficiently complete  engineering  definition  to  either  enable  in-house  production  or 
production  by  any  competent  manufacturer. 

Because  the  engineering/manufacturing  data  base  is  developed  to  satisfy 
the  requirements  of  those  two  disciplines,  it  does  not  adequately  address  the  needs 
of  the  content  generator.  Engineering  drawings  and  specifications  are  prepared 
with  only  the  data  necessary  to  build  and  test  the  hardware  in  a factory  and  do  not 
contain  the  detail  or  emphasis  that  is  needed  in  the  technical  manual.  For  example, 
testing,  troubleshooting,  and  alignment  procedures  developed  by  the  engineering 
activity  for  the  factory  environment  may  be  totally  inappropriate  in  the  field  en- 
vironment due  to  differences  in  available  support  and  test  equipment.  In  addition, 
they  often  contain  manufacturing  process  notes  that  are  of  no  use  to  the  TM  de- 
velopers or  users.  As  a result,  the  transformation  of  this  data  base  into  usable  tech- 
nical information  is  often  expensive  and  ineffective. 

Improving  the  Data  Base  - The  preliminary  concept  woujd  improve  the  data 
base  content  by  modifying  content  requirements  to  include  the  addition  of  mainte- 
nance data  (wear  tolerances,  torque  requirements,  signal  waveforms,  and  voltage 
levels,  etc.)  to  the  already  existing  design  and  manufacturing  data.  The  addition 
of  wear  tolerances,  for  example,  provides  the  source  data  to  determine  when  an 
item  has  reached  the  point  where  its  failure  is  imminent  and  repair  or  replacement 
is  required.  Voltage  levels  and  waveforms  are  examples  of  electronic  equipment 
maintenance  data  that  enables  the  content  generator  to  develop  accurate  mainte- 
nance and  troubleshooting  procedures.  The  addition  of  maintenance  data  to  the 
design  and  manufacturing  data  already  contained  in  the  engineering/manufacturing 
data  base  is  accomplished  by  the  replacement  or  modification  of  MlL-STD-100  to 
fit  the  added  data  needs  of  the  content  generator. 

Maintaining  accuracy  and  currency  of  the  engineering/manufacturing  data 
base  presents  additional  problems  to  the  content  generator.  This  is  because  of  the 
present  manual  methods  that  are  used  to  document  and  distribute  the  data  base. 

The  design  is  developed  by  the  engineering  staff,  documented  by  draftsmen,  check- 
ed by  checkers,  and  then  submitted  to  some  form  of  document  control  system  for 
storage,  reproduction,  and  distribution  to  users.  Any  formal  changes  to  the  docu- 
mentation that  are  prepared  during  hardware  manufacture  are  valid  for  changing 
the  manufacturing  process  the  moment  they  are  approved.  An  example  of  this 
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type  of  change  is  a manufacturing  activity  that  generates  an  engineering  order 
(floor  EO).  Since  the  EO  satisfies  the  manufacturing  process  needs  immediately, 
it  is  not  critical  to  the  engineering  or  manufacturing  activity  to  have  the  affected 
drawings  updated  immediately.  As  a result  of  the  delay  caused  by  the  normal  pro- 
cessing time  for  document  control,  reproduction,  and  distribution  of  the  EO,  the 
content  generator  may  not  become  aware  of  the  change  for  several  weeks  or  more. 
With  the  limited  time  available  for  developing  TMs,  any  delay  in  the  receipt  of 
change  information  results  in  delayed  rewrite  efforts.  This  becomes  especially 
critical  near  the  end  of  the  writing  effort  if  incorporation  of  the  change  requires 
a major  rewrite. 

In  the  NTIPS  preliminary  concept,  the  present-day  capabilities  of  computers 
and  their  peripheral  equipments  would  be  employed  to  provide  the  way  for  the  manu- 
facturer to  improve  data  base  accuracy  and  currency.  This  also  would  enable  him 
to  reduce  his  costs  and  improve  his  product  by  reducing  or  eliminating  many  re- 
petitive, time-consuming  tasks  now  required  in  the  manual  development  of  data 
bases.  Table  4-8  defines  the  basic  characteristics  of  the  proposed  concept.  Included 
are  the  types  of  controlling  documents,  data  types,  and  convertibility  to  T\1  char- 
acteristics, as  well  as  the  processing  form  with  its  data  management  method,  presen- 
tation medium,  and  accessibility  and  availability  characteristics. 

Methods  for  Generating  Data  Base  - In  order  to  meet  the  needs  of  large, 
medium,  and  small  engineering  activities,  various  methods  of  generating  the 
engineering/manufaeturing  data  base  are  accommodated  in  the  preliminary  con- 
cept. As  shown  in  the  table,  the  methods  vary  from  automating  all  or  part  of  the 
data  base  development  process  (fully  automated  and  semiautomated  systems  for 
large  and  medium  sized  activities)  to  manual  means  for  small  activities. 

The  fully  automated  generation  system  consists  of  a computer,  interactive 
graphic  terminals,  and  output  devices  for  developing  and  maintaining  the  data  base. 

In  this  system,  the  design  engineer  develops  his  design  and  performs  the  drawing 
checks  directly  on  an  interactive  graphic  terminal.  This  results  in  the  engineering 
drawings,  specifications,  and  all  other  pertinent  design  data  being  processed  and 
stored  in  digital  form  in  the  computer.  Output  devices  convert  the  digital  data 
to:  (1)  forms  that  manufacturing  requires  (numeric  controlled  tapes,  planning  docu- 
ments, drawings,  etc.)  to  produce  and  test  the  system,  equipment,  or  hardware 
product;  (2)  forms  required  to  meet  the  contract  data  requirements  (CDRLs);  and 
(3)  forms  to  meet  the  needs  of  the  content  generator.  Some  data  (such  as  mech- 
anical and  schematic  diagrams)  is  directly  usable  as  technical  information  while 
other  data  (e.g.,  system  test  procedures,  acceptance  test  specifications,  and  equio- 
ment  descriptions)  has  to  be  reviewed  and  analyzed  before  transformation.  The 
time-consuming  tasks  of  data  reproduction  and  distribution  associated  with  a man- 
ually generated  data  base,  as  well  as  the  accompanying  human  errors  and  controls 
required  to  reduce  those  errors,  are  eliminated.  Validity  of  the  data  base  is  main- 
tained by  the  inherent  data  management  and  conirol  feature  of  the  computer  program 
which  grants  permission  for  an  update  only  to  authorized  engineering  personnel. 

Any  design  errors  in  the  data  base  are  readily  corrected  by  the  design  engineer  using 
his  interactive  graphic  terminal. 

To  the  content  generator,  the  automated  data  base  provides  immediate 
access  through  interactive  graphic  terminals  eliminating  the  time  delays  associated 
with  manually  reproduced  and  distributed  data.  For  example,  when  a writer  requires 
a specific  diagram,  he  uses  his  interactive  graphic  terminal  to  call  it  up  for  display. 

If  he  needs  a copy,  he  then  uses  an  output  device  (x-y  plotter)  to  produce  the  dia- 
gram. The  elimination  of  the  time  delay  also  increases  the  data  base  as  far  as  the 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  - Content  Generation  Subsystem 

4.2.2  DESCRIPTION  OF  ENGINEERING/MANUFACTURING  DATA  BASE  (Continued) 


content  generator  is  concerned  because  the  diagram  he  sees  is  the  same  diagram 
the  designer  just  entered  into  the  system. 

For  a semiautomated  system,  the  same  type  of  data  processing  equipment 
is  used,  but  to  a limited  extent.  The  size  of  the  engineering  activity,  the  type  of 
system/equipment  manufactured,  and  available  capital  for  equipment  investment 
are  the  basic  criteria  that  determine  the  automation  level.  In  a design  activity 
with  a limited  number  of  interactive  graphic  terminals,  for  example,  the  design 
data  is  manually  generated  and  checked  by  the  design  engineer.  A draftsman  or 
clerk  then  enters  the  design  data  into  the  computer  through  his  interactive  graphic 
terminal.  Access  to  this  data  base  is  also  limited  by  the  number  of  terminals  avail- 
able and  user  demands.  Any  part  of  the  data  base  that  is  manually  generated,  up- 
dated, stored,  reproduced  or  distributed  will  continue  to  suffer  from  the  same  prob- 
lems that  plague  any  manually  developed  data  base.  Manual  generation  is  limited 
to  small  activities  with  limited  funds  which  prohibit  purchase  of  data  processing 
equipment. 

Data  Base  Alternatives  - A limited  automated  capability  alternative  pro- 
vides an  engineering/manu^acturing  data  base  in  which  only  the  graphic  information 
(i.e.,  all  types  of  diagrams  and  schematics)  is  generated,  processed,  stored,  and  re- 
produced in  the  same  manner  as  the  preliminary  concept.  All  text  information 
Uest  specifications,  equipment  descriptions,  etc.)  is  manually  generated,  duplicated, 
and  distributed.  Data  base  content  requirements  (including  maintenance  data)  re- 
main the  same  as  for  the  preliminary  concept.  This  alternative  would  suffice  in 
most  cases  where  the  manufactured  product  is  strictly  mechanical  in  nature. 

A second  alternative  (limited  in  automated  capability  and  content)  is  simi- 
lar to  the  first  in  its  method  of  implementation.  The  difference  is  that  only 
engineering/manufacturing  data  is  developed  by  the  design  engineering  activity, 
as  is  done  today.  That  is,  no  maintenance  data  is  included  in  the  data  base  content 
requirements. 


TABLE  4-8.  NTIPS  ENGINEERING/MANUI 


Convertibility 


Engineering 

Activity 

Size 

Generation 

Method 

Content 

Requirements 

Controlling 

Documents 

Data  Types 

to 

Technical 

Information 

NTIPS  PRELIMINAR'' 

Large 

Automated  text 
and  illustra- 
tions 

Design,  manu- 
facturing and 
maintenance 
data 

MIL-STDs, 

MIL-SPECs, 

CDRLs 

Formal 
(deliverable) 
and  informal 
(non-deliveralole) 

Direct  and  ] 

indirect 

Medium 

Semi- 

automated  text 
and 

illustrations 

Same 

Same 

Same 

Same  ] 

1 

Small 

Manual  text 
and  illustra- 
tions 

Same 

Same 

Same 

Same 

LIMITED  AUTOMATED  < 

Large 

Automated 
illustrations 
and  manual 
text 

Design,  manu- 
facturing and 
maintenance 
data 

MIL-STDs, 

MIL-SPECs, 

CDRLs 

Formal 
(deliverable) 
and  informal 
(non -deliverable) 

Direct  and  ! 

indirect  1 

Medium 

Semi- 
automated 
illustrations 
and  manual 
text 

Same 

Same 

Same 

Same  1 

Small 

Manual  illus- 
trations and 
text 

Same 

Same 

Same 

Same 

LIMITED  AUTOMATED  CAPABILITY 

Large 

Automated 
illustrations 
and  manual 
text 

Design  and 

manufacturing 

data 

MIL-STDs, 

MIL-SPECs, 

CDRLs 

Formal 
(deliverable 
and  informal 
(non-deliverable) 

Indirect 

1 

Medium 

Semi- 
automated 
illustrations 
and  manual 
text 

Same 

Same 

Same 

Same 

Small 

Manual  illus- 
trations and 
text 

Same 

Same 

Same 

Same 

ING/MANUFACTURING  DATA  BASE  CHARACTERISTICS 


vertibility 

to 


pechnical 

feormation 

Processing 

Form 

Data  Management 
and  Control 

Revision 

Status 

Presentation 

Medium 

Accessibility 

Availability 

Storage 

|rELIMINARY  DATA  BASE  CONCEPT 

TCct  and 
Brect 

Digital 

Computer 

program 

Current 

Intelligent 

terminal, 

paper 

Immediate 

On  demand 

Disc,  mag  tape, 
paper  and 
microform 

me 

Digital/ 

paper 

Computer  pro- 
gram for  auto- 
mated aspect; 
document  con- 
trol for  paper 

Current 

(digital); 

delayed 

(paper) 

Same 

Immediate 
(digital);  de- 
layed (paper) 

On  demand 
(digital);  by 
request 
(paper) 

On  demand 
(digital);  by 
request 
(paper) 

me 

Paper 

Document 

control 

Delayed 

Paper 

Delayed 

By  request 

Paper  and 
microform 

^UTOMATED  CAPABILITY  ALTERNATIVE 

rect  and 
iirect 

Digital/ 

paper 

Computer  pro- 
gram for  auto- 
mated aspect; 
document  con- 
trol for  paper 

Current 

(digital); 

delayed 

(paper) 

Intelligent 

terminal, 

paper 

Immediate 
(digital);  de- 
layed (paper) 

On  demand 
(digital);  by 
request 
(paper) 

Disc,  mag  tape, 
paper  and 
microform 

me 

Same 

Same 

Same 

Same 

Same 

Same 

Same 

me 

Paper 

Document 

control 

Delayed 

Paper 

Delayed 

By  request 

Paper  and 
microform 

CAPABILITY  AND  LIMITED  CONTENT  ALTERNATIVE 

direct 

Digital/ 

paper 

Computer  pro- 
gram for  auto- 
mated aspect; 
document  con- 
trol for  paper 

Current 

(digital); 

delayed 

(paper) 

Intelligent 

terminal, 

paper 

Immediate 
(digital);  de- 
layed (paper) 

On  demand 
(digital);  by 
request 
(paper) 

Disc,  mag  tape, 
paper  and 
microform 

me 

Same 

Same 

Same 

Same 

Same 

Same 

Same 

me 

Paper 

Document 

control 

Delayed 

Paper 

Delayed 

By  request 

Paper  and 
microform 

Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  - Content  Generation  Subsystem 


4.2.3  DESCRIPTION  OF  ESTIMATING  FUNCTION 


The  TM  engineer  will  provide  improved  coordination  between  content  generation,  and 
the  design  engineering,  ILS,  and  quality  assurance  activities,  to  ensure  development 
of  realistic  and  integrated  TM  estimates. 

The  estimating  function  of  the  Content  Generation  Subsystem  is  the  initial 
point  at  which  the  content  generating  activity  becomes  involved  in  the  TM  develop- 
ment cycle  for  new  system/equipment  procurements  or  a TM  update  effort  for  in- 
corporating changes  and  modifications.  The  content  generator  uses  the  data  acqui- 
sition rules  specified  in  the  request  for  estimate,  in  conjunction  with  the  minimal 
engineering/manufaeturing  data  bases  available  at  this  time,  to  develop  a TM  esti- 
mate package. 

A coordination  problem  exists  because  the  interrelationships  between  the 
TM  activity,  the  design  engineering  activity,  and  the  ILS  elements  (training,  LSA 
engineering,  and  spares  provisioning)  are  not  normally  established  until  the  TM 
planning  efforts  are  initiated.  As  a result,  the  content  generator  is  forced  to  base 
the  TM  estimate  on  the  initial  design  data  furnished  by  the  design  activity.  Addi- 
tionally, without  coordination  with  the  other  ILS  elements,  the  compatibility  of 
the  TM  estimate  with  the  total  support  package  is  severely  limited. 

An  additional  coordination  problem  exists  because  the  interrelationship 
between  the  TM  activity  and  the  quality  assurance  activity  is  not  normally  estab- 
lished until  the  TMs  are  fully  developed.  Lacking  QA  guidance,  the  TM  activity 
may  not  be  fully  aware  of  the  QA  requirements  which  must  be  met  to  achieve  cus- 
tomer acceptance  of  the  TMs.  Gaining  this  knowledge  at  the  end  of  a program  may 
result  in  a costly  rewriting  effort  or  may  surface  as  a TM  revision  or  change  package. 

The  TM  Estimating  Process  - In  the  preliminary  concept,  the  TM  engineer 
would  be  responsible  for  designing  the  content  and  usability  of  the  technical  man- 
ual. This  process  is  started  during  the  precontract  award  phase  of  content  genera- 
tion when  the  TM  engineer,  functioning  as  TM  Proposal  Technical  Manager,  anal- 
yzes the  request  for  estimate.  He  then  reviews  hardware  specifications,  design 
disclosure  documents,  data  base  requirements,  and  maintenance  philosophy.  Sched- 
ules and  milestones  are  developed  dealing  with  availability  of  TM  critical  items, 
such  as  portions  of  the  deliverable  and  nondeliverable  data  base.  Additionally,  ten- 
tative plans  are  made  for  TM  developer  interrelationships  with  the  design  activity 
and  for  access  to  initial-delivery  equipment.  Working  closely  with  the  hardware 
proposal  management  team,  ILS  elements  and  the  QA  activity,  the  TM  engineer 
then  develops  the  TM  estimate  based  on  inputs  from  these  activities,  resulting  in 
a realistic  and  totally  integrated  response  to  the  request  for  estimate.  Guidance 
for  developing  the  TM  estimate  would  be  provided  to  the  TM  engineer  by  the  NTIPS 
TM  Development  Guide.  (See  topic  4.2.7.) 

Initially,  the  TM  estimating  effort  (Figure  4-8)  involves  identification  of 
(1)  TM  requirements.  Contract  Data  Requirements  List  (CDRL)  and  Technical  Manual 
Contract  Requirements  (TMCR);  (2)  system/equipment  descriptions,  including  vendor 
items;  (3)  schedules,  statement  of  work,  pricing  instructions,  etc.;  and  (4)  the  mainte- 
nance concept.  The  specific  QA  requirements  are  identified  and  combined  with 
the  activity's  basic  TM  program  requirements  to  form  the  basis  for  the  proposed 
TM  acquisition  QA  program. 

Based  on  the  above  information,  preliminary  estimates  of  the  TM  package 
size  and  content,  and  TM  milestones  and  schedules  are  developed.  The  TM  engineer 
evaluates  the  proposed  engineering/manufacturing  data  base  against  the  technical 
information  development  needs  identified  by  the  TM  requirements  to  determine  if  ad- 
ditional data  is  needed.  These  needs,  in  today's  world,  are  not  determined  until  after 
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the  hardware  acquisition  contract,  which  includes  the  data  base  content,  has  been 
awarded.  It  then  becomes  very  difficult  for  the  T\1  developer  to  obtain  the  data 
he  needs.  Some  of  the  reasons  are  the  design  engineer  is  not  contractually  covered 
to  develop  the  data,  or  his  time  is  so  limited  he  cannot  generate  the  data  when 
needed.  This  forces  the  content  generator  either  to  develop  the  data  himself  or 
leave  it  out  of  the  TM.  Placing  the  data  needs  on  design  engineering  during  the 
estimating  phase  enables  them  to  obtain  contractual  coverage,  thus  ensuring  data 
availability  to  the  content  generator. 

The  preliminary  TM  estimate  package,  including  any  additional  engineer- 
ing/manufacturing data  base  requirements,  forms  the  TM  input  to  an  ILS  estimate 
review  board.  The  review  team  composed  of  the  TM  engineer,  hardware  program 
manager,  design  engineers,  and  other  ILS  element  personnel,  review  all  ILS  element 
estimates.  Each  ILS  element's  input  is  individually  reviewed  for  impact  upon  other 
ILS  elements  and  design  engineering.  As  problems  are  identified,  solutions  with 
tlieir  attendent  risks  are  proposed  and  analyzed.  A final,  approved  TM  estimate 
package  is  then  prepared  and  delivered  to  the  TM  Acquisition  Subsystem. 

Estimating  Function  Alternatives  - The  first  alternative  deals  with  the 
problem  of  the  lack  of  a complete  and  well-defined  engineering/manufacturing  data 
base  when  the  TM  proposal  is  developed.  Since  the  TM  estimate  is  required  by  the 
procuring  activity  early  in  the  hardware  development  cycle,  only  an  incomplete, 
relatively  undefined  engineering/manufacturing  data  base  is  available  for  review. 
This  forces  the  estimator  into  a series  of  creative  guesses  as  to  equipment  com- 
plexity and  difficulty  of  presentation  development,  often  resulting  in  inaccurate 
estimates  of  TM  page  counts  and  man-hours.  The  consequences  can  be  particularly 
acute  when  dealing  in  high-technology  areas  where  the  state-of-the-art  is  extreme- 
ly dynamic.  The  tendency  to  compensate  by  overestimating  is  tempered  by  the 
realization  that  an  unrealistic  estimate  will  probably  not  result  in  a contract. 

Since  the  aim  of  the  content  generator  is  to  stay  within  budget,  the  only  variable 
which  can  be  manipulated  after  contract  award  is  TM  quality,  in  the  form  of  depth 
of  coverage,  with  a resultant  impact  on  page  count.  Compromises  and  shortcuts 
in  the  development  cycle  often  cause  ineffective  TMs  to  be  deployed  in  the  field. 
Ultimately,  higher  equipment  life-cycle  costs  result  due  to  the  increased  mainte- 
nance time  necessitated  by  TM  deficiencies. 

The  alternative  approach  in  this  type  of  situation  is  to  release  the  request 
for  estimate  at  a point  in  time  which  more  closely  corresponds  to  actual  TM  de- 
velopment. At  this  stage  of  the  program,  the  engineering  concept  is  firm,  hard- 
ware modifications  resulting  from  equipment  checkout  and  testing  are  fewer,  and 
a large  percentage  of  the  data  base  is  available.  As  a result,  the  content  generator 
is  now  able  to  more  realistically  evaluate  the  task  and  develop  an  accurate  TM 
estimate. 

The  second  alternative  is  concerned  with  the  problem  of  "estimating 
guesses"  that  make  it  extremely  difficult  to  determine  the  adequacy  of  TM  estima- 
ting procedures  because  of  the  lack  of  traceable  underlying  rationale.  This  prob- 
lem is  compounded  by  the  fact  that  while  actual  costs  may  correspond  to  estimated 
costs,  this  is  often  a forced  fit,  more  attributable  to  manipulations  of  TM  quality 
rather  than  to  the  accuracy  of  the  estimate. 

The  alternative  approach  to  this  problem  is  to  use  a computer  and  a special 
program  for  developing  the  TM  estimate.  The  computer  performs  the  actual  esti- 
mating effort  based  on  input  data  and  internally  stored  reference  information. 
Inputs  consist  of  the  TM  requirements,  system/equipment  descriptions  and 
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4.2.3  DESCRIPTION  OF  ESTIMATING  FUNCTION  (Continued) 


development  schedules,  TM  development  schedules,  and  the  TM  development  labor 

rates  and  material  costs.  Stored  in  the  computer  is  a TM  historical  data  file  that 

contains  all  the  same  type  of  information  describing  previously  developed  TMs.  1 

The  computer  compares  the  input  data  with  the  stored  data  and  attempts  to  estab-  | 

lish  a match.  When  a match  is  made,  the  computer  then  develops  the  final  estimate  , 

with  supporting  rationale.  If  only  e near  match  is  achieved,  the  computer  identifies  ; 

the  differences,  establishes  the  difference  factors,  and  then  uses  these  factors  to 

develop  the  final  estimate  and  rationale. 
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Figure  4-8.  Estimating  Function.  These  procedures,  with  minor  exc 
Navy  in-house  and  contractor  activities  generating  TM  estimates. 


re  4-8.  E.stimating  Function.  These  procedures,  with  minor  exceptions,  are  applicable  to  hotli 
’ in-house  and  contractor  activities  generating  TM  estimates. 
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4.2.4  DESCRIPTION  OF  PRODUCT  PLANNING  SUBFUNCTION 


The  TM  engineer  will  develop  detailed  TM  planning  documents  (e.g.,  bookplans)  custom- 
ized to  particular  systems/equipments.  In  addition,  coordination  with  other  ILS  ele- 
ments ensures  that  the  TM  planning  documents  are  compatible  with  the  overall  ILS 
package  planning. 

Product  planning  normally  occurs  during  the  first  30  to  60  days  after  con- 
tract award.  This  is  the  period  during  which  technical  publication  plans  and  TM 
bookplans/outlines  are  developed  by  the  content  generator  and  approved  by  the  TM 
Acquisition  Subsystem.  A technical  publication  plan  contains  information  as  to 
the  number  and  type  of  TMs  to  be  developed  for  each  of  the  systems  and/or  equip 
ments  being  procured.  A TM  bookplan/ outline  presents  in  general  terms  the  contents 
of  each  TM  by  chapter,  section,  and  paragraph  and  often  includes  samples  of  the 
types  of  procedures,  descriptions,  and  illustrations  to  be  included.  After  development 
by  the  content  generator,  the  TM  planning  documents  are  reviewed  and  approved 
by  the  cognizant  military  agency.  These  plans  are  then  used  by  the  content  gener- 
ator and  by  the  reviewing  agency  as  a monitoring  baseline. 

The  development  of  TM  planning  documents  is  the  critical  first  step  in  the 
development  of  TMs  which  are  effective  and  usable  in  the  field.  The  problem  is 
that  technical  publication  plans  and  TM  bookplans/outlines  are  vague,  nondetailed, 
and  usually  contain  only  "boilerplate"  information.  Due  partially  to  the  minimal 
engineering/manufacturing  data  base  content  available  at  this  time,  these  documents 
are  not  designed  for  the  specific  TMs  to  be  developed,  and  often  merely  repeat  what 
is  contained  in  the  TM  specification. 

An  additional  problem  is  the  compatibility  of  the  TM  planning  documents 
with  those  of  the  other  ILS  elements  (e.g.,  training,  LSA  engineering,  spares  pro- 
visioning, etc.).  Presently,  their  development  is  not  coordinated,  resulting  in  a sup- 
port package  that  does  not  adequately  meet  the  user  needs. 

Subfunction  Preliminary  Concept  - In  the  preliminary  concept,  the  TM  engi- 
neer would  establish  the  interrelationsmp  with  the  design  activity  and  prepare  a 
"first-order  cut"  at  detailed  planning,  limited  only  by  the  preliminary  nature  of  the 
system/equipment  definitions.  The  resulting  preliminary  TM  bookplan  requirements 
would  then  be  submitted  to  the  ILS  program  review  team  to  be  reviewed  for  com- 
patibility with  the  overall  support  program  (i.e.,  training,  logistic  support  analysis, 
and  spares  provisioning)  planning.  Based  on  the  results  of  the  review,  the  TM  engi- 
neer would  develop  detailed  planning  documents  specifically  tailored  to  the  hardware 
and  support  package  being  acquired.  These  documents  would  then  be  submitted 
to  the  TM  Acquisition  Subsystem  for  approval. 

Additionally  the  TM  engineer  would  be  responsible  for  ensuring  that  all  the 
engineering  documentation  including  drawings,  test  specifications,  wiring  lists,  etc., 
will  be  prepared  in  formats  that  not  only  meet  the  minimum  requirements  for  manu- 
facturing arr  ‘rst  but  also  are  TM-compatible. 

To  assist  the  TM  engineer  in  product  planning,  guidance  would  be  provided 
through  the  N UPS-developed  FM  Development  Guide.  Refer  to  Topic  4.2.7  for 
a detailed  discussion  of  this  guide. 

Product  Planning  Activities  - Figure  4-9  illustrates  the  tasks  involved  in 
the  preliminary  concept  fcr  product  planning.  The  initial  step  in  the  process  is  the 
identification,  based  upon  contractual  information,  of  tlie  TM  bookplan  data  items, 
validation/verif ication  requirements,  vendor  TMs,  and  GFP  to  be  supplied.  From 
this  information  the  TM  bookplan  requirements  are  defined.  In  parallel  with  this 
activity,  the  engineering/manufacturing  and  LSA  data  base  requirements  are  eval- 
uated for  TM  compatibility  and  maintenance  data  coverage. 
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(liven  till  of  the  information  generated  thus  far,  an  ILS  program  review  team 
(composed  of  the  TM  engineer  and  representatives  from  each  ILS  element)  is  con- 
vened. This  team  is  responsible  for  coordinating  all  ILS  planning  in  order  to  generate 
u complete  support  package  (e.g.,  TMs,  user  training  and  training  aids,  logistic  sup- 
port analysis,  and  spares  provisioning)  that  meets  the  system /equipment  operational 
and  maintenance  requirements.  In  the  event  of  conflict  between  ILS  elements,  the 
program  review  team  will  evaluate  the  point(s)  of  contention  and  provide  a joint 
resolution  of  the  problem(s). 

The  ILS  review  team  will  identify  any  inadequacies  in  the  engineering/ 
manufacturing  and  LSA  data  bases,  such  as  missing  maintenance  data,  instructions, 
or  procedures  whicli  were  not  possible  to  identify  during  the  TM  estimating  process, 
as  well  as  any  problems  associated  with  hardware  availability.  Recommended  solu- 
tions will  be  formulated  for  all  problems  identified  (e.g.,  redundancies  in  TMs  and 
training  data,  incompatible  schedules,  conflicting  specifications,  differences  in  main- 
tenance level  and  spares  provisioning,  data  base  inadequacies,  etc.)  as  well  as  assess- 
ment of  the  risks  (to  TM  developers  and  other  iLS  elements)  inherent  in  implementing 
tliese  recommendations.  The  recommendations  and  associated  risks  related  to  the 
engineering/manufacturing  data  base  are  then  submitted  to  design  engineering  for 
review  and  action.  The  results  of  any  tradeoffs  that  impact  contractual  requirements 
are  forwarded  to  the  ILS  manager  for  subsequent  negotiations  with  the  TM  Acquisi- 
tion Subsystem.  Based  upon  the  results  of  design  engineering  action  and,  as  applic- 
able, contract  changes,  finalized  requirements  for  TMs  and  other  ILS  products  are 
established. 

1 he  I'M  engineer  then  prepares  the  detailed  TM  bookplan  and  outline  based 
on  these  requirements.  A component  of  these  requirements,  the  NTIPS-developed 
modular  specification,  provides  the  TM  engineer  with  the  top  level  TM  bookplan 
and  outline  down  to  a chapter  or  section.  Additionally,  the  modular  specification, 
ii  based  upon  the  user-data  match  model,  identifies  the  technical  content  and  presen- 

1'  tation  techniques  for  each  chapter  or  section.  Using  this  information  and  the  system/ 

i equipment  descriptions,  the  TM  engineer  develops  the  bookplan  and  outline  detailed 

[ to  the  paragraph  level.  The  modular  specification  provides  the  TM  engineer  with 

j a major  advantage  over  the  traditional  specifications  in  that  it  is  custom-fitted 

j to  the  specific  system/equipment  being  procured.  The  various  technical  content 

j and  presentation  techniques  to  be  employed  to  meet  the  user's  needs  are  defined 

by  chapter  or  section.  This  is  especially  beneficial  for  a system  employing  multiple 
disciplines  (e.g.,  mechanical,  electrical,  and  electronic  subsystems  contained  in 
\ an  aircraft  carrier's  elevator  or  an  automated  propulsion  plant). 

; For  example,  the  technical  content  for  the  electronics  portion  of  an  elevator 

‘ may  require  theory  of  operation,  troubleshooting  information,  and  repair  data  such 

1 as  removal  and  replacement,  alignment  and  adjustment  procedures.  In  developing 

I the  TM  bookplan  and  outline,  the  TM  engineer  is  able  to  confirm  the  validity  of 

; the  specifications  against  the  hardware  descriptions  at  this  meaningful  level.  Should 

a problem  arise,  he  can  prepare  recommended  changes  and  submit  the  changes  in 
specific  modular  terms  as  part  of  the  final  bookplan  and  outline  submittal.  The 
J presentation  techniques  employed  to  support  the  technical  content  may  consist  of 

I coded  block  diagrams  for  theory  of  operation,  maintenance  dependency  charts  for 

i troubleshooting,  and  line  drawings  highlighting  the  item(s)  associated  with  the  re- 

I pair  procedure.  Again,  the  TM  engineer  confirms  the  validity  of  these  specifications 

and  prepares  recommended  changes  if  necessary. 

Although  the  technical  content  and  presentation  techniques  required  for 
; the  elevator's  mechanical  portion  are  different  (for  example,  requiring  only  trouble- 
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shooting  information  with  decision  flow  diagrams,  and  repair  procedures  with  ex- 
ploded view  mechanical  assembly  diagrams),  the  TM  engineer's  bookplan  and  outline 
development,  and  specification  validity  confirmation  tasks,  are  the  same  as  for 
the  electronics  portion. 

The  result  is  a detailed  TM  bookplan  and  outline  that  is  customized  to  a 
specific  TM  procurement,  reflects  real  user  needs,  and  provides  explicit  TM  devel- 
opment direction  with  examples  to  the  TM  writer. 

Product  Planning  Subfunction  Alternatives  - A viable  alternative  is  the 
time-phased  developmeirt  of  TM  planning  documents.  This  alternative  is  based  on: 

(1)  these  documents  are  not  needed  until  a short  time  (approximately  60  days)  be- 
fore the  actual  start  of  the  writing  effort,  and  (2)  the  engineering/manufacturing 
data  base  detailed  information  becomes  available  in  increments  as  each  step  in  the 
hardware  design  is  completed. 

A key  ingredient  in  the  development  of  TM  bookplans  and  outlines  is  system/ 
equipment  knowledge.  To  tailor  technical  publication  plans  and  TM  bookplans  and 
outlines  to  unique  system/equipment  characteristics,  requires  substantially  firm 
equipment  design  data.  This  data  is  not  available  immediately  after  contract  award, 
but  becomes  available  in  increments  as  the  design  progresses  from  contract  award 
to  the  start  of  technical  information  generation.  However,  several  methods  of  de- 
veloping time-phased  TM  planning  documents  are  available:  the  method  selected 
depends  on  the  size  of  TM  program.  For  a relatively  small  program,  the  planner 
delays  the  start  of  planning  until  the  majority  of  the  design  is  complete  and  firm 
engineering  data  is  available.  The  only  restriction  here  is  that  the  TM  planning 
documents  must  be  completed  and  submittted  to  the  TM  Acquisition  Subsystem 
in  sufficient  time  for  review  and  approval  prior  to  the  actual  start  of  the  writing 
effort. 

Another  method  available  to  the  planner  is  to  prepare  and  submit  a prelim- 
inary TM  bookplan,  with  a skeletal  outline,  within  60  days  after  contract  award. 

This  enables  the  TM  Acquisition  Subsystem  to  review,  at  an  early  date,  the  general 
approach,  and  the  presentation  techniques  to  be  used.  When  the  design  engineering 
data  becomes  firm,  the  planner  develops  and  submits  the  detailed  TM  outline.  Any 
comments  by  the  TM  Acquisition  Subsystem  on  the  basic  TM  planning  documents, 
and  any  modifications  that  result  from  design  engineering  changes  are  incorporated 
in  this  submittal.  This  second  submittal  is  developed  in  sufficient  time  to  allow 
for  review  and  approval  prior  to  the  actual  start  of  the  writing  effort.  This  method 
is  applicable  to  medium  and  relatively  large-scale  TM  acquisition  programs. 

In  a variation  of  the  above,  incremental  packages  can  be  developed  and 
submitted  for  review  and  approval  as  various  parts  of  the  engineering  design  are 
completed.  This  enables  the  TM  outlines  to  be  developed  over  a period  of  lime, 
eliminating  a big  effort  just  prior  to  the  start  of  the  writing  effort. 
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tDENTIFY  TMCONTWACT 
DATA 


DEFINE.  TW  BOOKPLAN 
REQUIREMENTS 


TM  Contract 


Identify  items  related  to  TM  bookplarrs: 

• CDRL/TMCR 

• Equipment  development  and 
delivery  niilestones  and  schedules 

• Statement  of  work 

• Maintenance  concept 

• GFP  to  be  supplied 

• Validation  and  verification  plan 
requirements 

• TMs  to  be  subcontracted  and 
delivery  schedules 

• Equipment  vendor  supplied  TM 
and  delivery  schedules 

• Quality  assurance  requirements 


Bookplan 
Data  Items 


• Identify  froni  T M bookplan 
CDRL/TMCR: 

1.  Data  Item  descriptions 

2.  Specificatiof<s 

3.  Standards 

4.  All  exceptions  and  vanations 

5.  Medium  for  final  TMs 

6.  Deliverable  quantities 

7.  Quality  assurance  requirements 

• Review  and  anaiy/e  requirements 

• Resolve  any  conflicts 

• F inaii/e  T M bookplan 
requirements 


Validation/Verification  Plan  Requirements, 
Vendor  T Ms 


Deliverable  System/ 
Equipment  Engineering 
Data  Base 


Non-Deiiverabte  System/ 
Equipment  Engineering 
Data  Base 


REVIEW  FINALIZED 

TECHNICAL  DATA  BASE 

• Review  following  Items  for  compatibility 

with  technical  data  base  lequirements: 

1. 

Contracted  design  engineering  data 

2. 

In-house  use  engineering  descriptions 

3. 

Software  program  descriptions  (oper- 
ation, checkout,  evaluation,  comput- 
er diagnostics) 

4. 

Vendor  supplied  TMs 

5. 

Existing  government  furnished  publi- 
cations 

6. 

Logistic  support  analysis 

7. 

Level  of  repair 

8. 

Illustrated  parts  breakdown;  equip- 
ment assembly,  subassembly  and 
module  illustrations 

NOTE: 

This  diagram  represents  the  maximum  configuration. 
Tasks  may  be  done  in  truncated  form  depending  on 
Size  of  TM  activity,  size  of  TM  effort,  and  method  of 
conducting  business. 
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OUT  LINES 
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CDRL/TMCR: 

1.  Data  Item  descriptions 

2.  Specifications 

3.  Standards 

4.  AM  exceptioiis  and  vai  lations 

5.  Medium  for  filial  TMs 

6.  Deliverable  quantities 

7.  Quality  assurance  requirements 

Review  and  analyze  requirements 
> Resolve  any  conflicts 

Finalize  TM  bookplan 
requirements 


n Plan  Requirements, 


Bookplan 

Requirements 


Other  ILS 
Elements 
Planned 
Efforts 


IPB  & Spares 


Test  Equipment 


Convene  ILS  program  review  team 
For  each  ILS  element,  review: 

1.  Product  requirements 

2.  Quality  assurance  requirements 

3.  Deliverable  Item  descriptions 

4.  Data  requirements  with  design 
engineering  and  other  elements 

5.  System/equipment  availability 
requirements 

For  each  ILS  element,  Identify  prob- 
lem areas  and  conflicts  found  In 
review 

Resolve  conflicts  between  ILS  ele- 
ments 

Develop  solutions  to  problems 
Define  risks  Involved  In  solutions 

Provide  ILS  manager  with  technical 
support  In  meetings  with  design  eng- 
ineering and  customer  to  evaluate 
solutions  and  finalize  requirements 


Finalized  Bookplan 
Requirements 


Review  an  avaiiabie  design 
engineering  data 

Develop  TM  outlines  based 
on  fmali^ed  bookplan  require- 
ments and  design  engineeimg 
data 

Identify  TM  to  be  developed: 


2.  Subcontractor 

Describe  methods  and  procedu 
for: 

1.  In-house  development, 
validation,  verification  and 
delivery  of  TMs 

2.  Supporting,  monitoring  dev 
opment  and  accepting  sub- 
contractor developed  TMs 

3.  Reviewing  and  accepting  eq 
ment  vendor  supplied  TMs 

4.  Integrating  in-house  and  sul 
contractor  developed  TMS 
with  equipment  vendor 
supplied  TMs  and  governm« 
furnished  publications 

5.  Developing  and  implement! 
validation  and  verification  p 

Assemble  TM  outlines,  and  des 
tions  of  methods  and  procedur 
into  TM  bookpians/outlines  as 
prescribed  by  CDRL/TMCR 
requirements 
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PREPAHE  TM  BOOKPLANS/ 

outlines 


TM  BOOKPLANS/OUTLINES 
REVIEW 


Inaii^ed  Bookpian 
[•Quirernents 


Review  all  available  design 
engineering  data 

Develop  TM  outlines  based 
on  f'Oalized  bookplan  require- 
mei'ts  and  design  engineering 
data 

Identify  TM  to  be  developed: 


2.  Subcontractor 

Describe  methods  and  procedures 
for: 

1.  ln*house  development, 
validation,  verification  and 
delivery  of  TMs 

2.  Supporting,  monitoring  devel- 
opment  and  accepting  sub- 
contractor developed  TMs 

3.  Reviewing  and  accepting  equip- 
ment vendor  supplied  TMs 

4.  integrating  in-house  and  sub- 
contractor developed  TMs 
with  equipment  vendor 
supplied  TMs  and  government 
furnished  publications 

5.  Developing  and  implementing 
validation  and  verification  plans 

Assemble  TM  outlines,  and  descrip- 
tions of  methods  and  procedures 
into  TM  bookplans/outlines  as 
prescribed  by  CDRL/TMCR 
requirements 


TM  Book- 
pians/Outlines 


Publications  and  quality  assurance 
personnel  review  bookplans/ 
outlines  for  response  to: 

CDRL/TMCR 

2.  Statement  of  work 

3.  Maintenance  concept 

Revise  bookplans/outlines  to 
resolve  any  problems  or 
conflicts 


TM  Bookplans 


Submit  TM  bookplans/outlines  to 
TM  Acquisition  Subsystem  for 
review  and  approval  60  days  after 
contract  award 


TM  Bookplans/ 
Outlines  Approval 


FINALIZE  APPROVED  TM 
BOOKPLANS/OUTLINES 


Review  any  TM  Acquisition  Subsystem 
comments 

Resolve  any  conflicts  or  problem  areas 

Prepare  final  approved  TM  bookplans/ 
outlines 


Approved  TM 
Boo  kpians/Out  lines 


Figure  4-9.  NTIPS  Product  Planning  Subfunction.  Product  plans  developed  from  TM  requirements 
and  evaluated  with  other  ILS  plans  maintain  the  planning  balance  needed  to  meet  the  user  needs. 
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Tasking  of  the  TM  engineer  to  do  a better  job  of  upgrading  the  writing  staff  and  match- 
ing the  writers  to  the  various  work  packages  would  provide  major  improvements  to 
the  writing  effort.  

The  operational  planning  (Figure  4-10)  occurs  at  the  start  of  the  actual  TM 
development  cycle.  At  this  point,  the  hardware  development  process  has  evolved 
into  an  engineering/manufacturing  data  base  which  is  sufficiently  complete  for  TM 
generation  purposes.  During  this  phase,  the  approved  TM  planning  documents  (de- 
veloped in  product  planning)  are  converted  into  writing  work  packages.  Validation/ 
verification  plans,  internal  schedules  and  milesto.nes,  and  program-unique  writer's 
guides  are  also  developed. 

In  the  preliminary  concept,  the  TM  engineer  would  prepare  a detailed  book- 
plan  that  is  itemized  to  the  page  level.  This  bookplan  would  detail  the  required 
content  and  presentation  technique  for  each  subject  area.  Development  of  this 
bookplan  requires  the  active  participation  of  TM  supervisors  and  writers,  training 
personnel,  and  logistic  engineering  disciplines.  This  would  ensure  that  the  material 
presented  in  the  technical  manual  is  compatible  with  the  training  data  highlighted 
in  the  classroom/laboratory  sessions,  and  that  the  maintenance  data  reflects  the 
engineering  analysis  of  the  tasks  to  be  performed  at  the  established  maintenance 
level.  Operational  planning  guidance  for  the  TM  engineer  would  be  provided  in  the 
TM  Development  Guide.  Refer  to  Topic  4.2.7  for  a detailed  discussion  of  this  guide. 

Matching  the  Writer  to  the  TM  Work  Package  - A critical  step  in  TM  de- 
velopment  is  developing  the  match  between  the  writer  work  package  and  the  writing 
staff.  Unfortunately,  a problem  exists  in  that  the  writing  staff  members  are  fre- 
quently assigned  individual  work  packages  solely  on  the  basis  of  availability,  with 
little  consideration  given  to  individual  skills  and  experiences.  Consequently,  the 
quality  of  the  technical  information  suffers  as  a result  of  a less  than  optimum  trans- 
formation of  the  engineering/manufacturing  data  base  into  the  technical  manual. 

For  example,  a technical  writer  with  a background  in  complex  electronic  systems 
has  greater  difficulty  in  preparing  TMs  for  mechanical  systems  than  does  a mech- 
anically oriented  writer.  Even  within  the  same  type  of  system,  writers  experienced 
in  the  development  of  more  abstract  information  (e.g.,  theory  of  operation)  are 
not  equally  effective  in  developing  technical  information  that  is  more  concrete, 
or  mechanical,  in  nature  (e.g.,  removal  or  installation  procedures). 

During  operational  planning,  the  TM  engineer  defines  the  work  package 
technical  writer  requirements  and  identifies  the  writing  staff  capabilities  and  limi- 
tations. A preliminary  match  is  performed  to  determine  the  adequacy  of  the  writing 
staff's  capabilities.  If  a need  exists,  several  techniques  are  available  to  the  TM 
p engineer  to  upgrade  the  writing  staff.  Some  have  a rather  limited  effect,  while 

[ others  provide  a broader  impact.  Requiring  writers  to  be  graduate  engineers  with 

j degrees  related  to  the  field  of  endeavor  (i.e.,  mechanical,  electrical,  electronic, 

etc.)  is  one  technique.  However,  while  this  may  improve  the  technical  accuracy 
of  descriptive  material  (e.g.,  theory  of  operation,  system/equipment  description), 
maintenance  data  (e.g,,  troubleshooting)  may  decrease  in  quality  because  of  the 
writer's  lack  of  hardware  and/or  field  experience.  A second  technique  is  to  provide 
the  writers  with  "hands-on"  equipment  experience  during  hardware  development. 
This  would  upgrade  the  accuracy  of  maintenance  data,  but  the  effect  on  the  tech- 
nical accuracy  of  descriptive  material  may  be  limited.  However,  combining  these 
two  techniques  enables  the  writers  to  develop  technically  accurate  TMs,  which  are 
I responsive  to  the  user's  needs. 
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A third  technique  to  improve  the  technical  writers'  capabilities  is  for  the 
content  generator  to  develop  and  conduct  writer  training  courses.  These  courses 
consist  of  regularly  scheduled  sessions  oriented  toward  improving  present  abilities 
and  introducing  new  writing  methods  and  techniques.  Additional  system/equipment 
familiarization  courses  would  be  conducted  by  the  design  engineering  activity  on 
an  "as  required"  basis  to  acquaint  the  technical  writing  staff  with  the  hardware 
for  which  they  are  developing  the  supporting  technical  information. 

Coordination  With  Other  Activities  - As  part  of  the  operational  planning 
effort,  the  engineer  establishes  interrelationships  with  support  (i.e.,  illustration, 
composition,  and  production)  and  quality  assurance  activities.  This  ensures  the  plans 
developed  by  these  activities  are  responsive  to  the  TM  requirements,  milestones, 
and  schedules.  Early  coordination  with  quality  assurance  personnel  can  minimize 
the  problems  encountered  during  TVl  development  as  a result  of  different  interpre- 
tations of  contract  requirements,  specifications,  and  standards. 

During  operational  planning,  the  T\1  engineer  interrelates  with  design  engi- 
neering and  the  ILS  elements  to  review  hardware  and  ILS  element  development 
schedules.  The  purpose  is  to  identify  any  schedule  problems  that  would  affect  TM 
development.  These  problems  result  from:  (1)  delayed  availability  of  engineering/ 
manufacturing  and  logistic  data  bases;  (2)  delayed  availability  of  hardware  to  writers 
during  TM  development;  (3)  limited  availability  of  operational  hardware  during 
scheduled  validation  activities;  or  (4)  limited  accessibility  to  design  engineers  for 
consultation  with  writers.  The  TM  engineer  then  will  evaluate  each  potential  prob- 
lem thus  identified  and  formulate  a contingency  plan  to  minimize  the  problem's 
impact  on  the  TM  development  effort. 

TM  Writer's  Instructions  - Part  of  the  operational  planning  is  to  supply  the 
writing  staff  with  detailed  writing  instructions  and  guidance  in  addition  to  that  pro- 
vided in  the  TM  bookplans  and  outlines.  These  instructions  are  provided  in  a writer's 
guide  developed  by  the  TM  engineer.  This  writer's  guide  is  not  to  be  confused  with 
the  TM  Development  Guide  (discussed  in  topic  4.2.7),  which  is  used  exclusively  by 
the  TM  engineer.  The  writer's  guide,  tailored  to  the  TM  acquisition,  covers  such 
items  as  writing  style,  use  of  specific  terms  and  words,  techniques  for  transforming 
material  contained  in  the  engineering/manufacturing  data  base  to  TM  manuscript 
and  participation  in  in-process  reviews.  The  TM  engineer  prepares  the  guide  by 
selecting  applicable  instructions  from  contractual  documents  (e.g.,  statement  of 
work,  exceptions  and  variations,  CDRLs/TMCRs,  data  item  descriptions,  specifica- 
tions, and  standards),  existing  writer's  guides  from  previous  TM  programs,  and  any 
standards,  practices  and  directives  peculiar  to  the  TM  developing  activity.  These 
instructions  are  then  combined  with  those  furnished  by  the  TM  Acquisition  Subsystem 
to  form  a complete  writer's  guide  (see  topic  4.2.8  for  details). 

Operational  Plainning  Subfunction  Alternatives  - Qualification  of  technical 
writers  through  an  NTIPS  - designed  and  developed  certification  program  is  an  alter- 
native to  insure  that  technical  writer  capabilities  meet  the  TM  program  require- 
ments. Certifying  a technical  writer  is  similar  to  having  a person  complete  an  ap- 
prenticeship program  before  allowing  him  to  become  a journeyman  in  his  specific 
trade.  During  his  apprenticeship,  the  writer  is  trained  in  all  facets  of  technical 
writing  by  experienced  writers.  For  example,  he  learns  how  to:  (1)  review  TM  speci- 
fications to  obtain  descriptions  of  TM  types,  format,  style  and  content;  (2)  analyze 
the  engineering/manufacturing  data  base  for  applicability  as  technical  information; 
(3)  transform  technical  data  to  technical  information  in  the  different  presentation 
techniques;  and  (4)  participate  in  validation/verification  exercises.  This  program 
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would  verify  that  the  writer  has  had  the  education,  training,  and  experience  neces- 
sary to  meet  the  job  requirements. 

A second  alternative  is  to  subcontract  all  TM  development  to  data  houses, 
thereby  reducing  or  in  the  case  of  a small  Navy  activity,  eliminating  the  need  for 
an  in-house  writing  staff.  The  contractor's  TM  activities  would  be  staffed  by  TM 
program  management  personnel  only.  In  turn,  these  individuals  evaluate  the  TM 
estimates  submitted  by  approved  data  houses,  and  award  contracts  to  the  selected 
subcontractors.  In  addition,  in-process  reviews,  validation/verification,  and  final 
TM  acceptance  £ire  under  the  cognizance  of  the  TM  activity. 

A variation  of  this  alternative  is  to  use  data  houses  on  a limited  basis.  This 
allows  the  TM  activities  to  maintain  their  writing  staffs  at  a constant  level  by  sutv 
contracting  only  the  TM  development  programs  which  exceed  in-house  capabilities. 


I 

i 
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IDENTIFY  TM  DEVELOPER 


DEVELOP  DETAILED 
TM  BOOKPLANS 


Subcontractor  TM  (TM  sub- 
contracted to  a TM  or  data  house) 

Equipment  vendor  TM  (TM 
developed  by  manufacturer 
of  equipment  procured  by 
prime  contractor) 

Government  furnished 
publications 


From  m-house  TM  book  outline, 
prepare  detailed  TM  bookplans 
describing  content  of  each  page 
including  illustrations 


Subcontractor 

TM 


DEFINE  SUBCONTRACTOR 
TM  REQUIREMENTS 


Based  on  contract  requirements 
and  identified  TMs  define: 

• TM  requirements  and 
acceptance  criteria 

• Development  schedules  and 
milestones 


Subcontractor 
and  Equipment 
Vendor  TMs 


From  in-house  TM  bOoM 
identify  work  packages  j 
to  one  of  following: 


1.  Installation 

2.  Repair  i 

3.  Remove  and  reptfl 

4.  Operation 

5.  Preventive  maintsi 

6.  Corrective  mainM 

7.  Adjustment/ailgoi 

8.  Troubleshooting  ; 

9.  Theory  of  oper«t( 

Equipment  cha  ract«( 

1 . Mechanical  | 

2.  Electrical  i 

3.  Electronic 

4.  Hydraulic  | 

5.  Pneumatic  j 

Book  divisions  | 

1.  Chapters  - 

2.  Sections  I 

3.  Subsections  j 


Subcontractor  TM  Validation 
and  Verification  Requirements 


Contract 

Requirements 


Validation  and  verification 
requirements 


Guidance  and  in-process 
review  requirements 


Subcontractor  TM 
Requirements 


To  Subcontractor 


Quality  assurance  requirements  I Subcontractor  Schedules  and  Milestones 

I Subcontractor  Qualify  Assurance  Requirements 


Contract 

Requirements 


List  of 

Purchased 

Equipment 


DEFINE  EQUIPMENT  VENDOR 
TM  REQUIREMENTS 


Based  on  contract  requirements, 

equipment  being  purchased  and 

identified  TM,  define: 

• Delivery  schedules  and 
acceptance  criteria 

• Vendor  TM  review 

• Methods  and  procedures  for 
resolution  and  incorporation 
of  review  comments 

• Progress  reports 

• Specifications  and  standards 


Equipment  vendor  TM  Validation 
and  Verification  Requirements 


Equipment  Vendor 
TM  Requirements 


Equipment  vendor  Quality 
Assurance  Requirements 


• Quality  assurance  requirements 


Equipment  Vendor  Schedules  and  Milestones 
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IDENTIFY  WRITING 
WORK  PACKAGES 


Detailed 

TM 

Bookplan 


From  m-house  TM  bookpians 
identify  work  packages  oriented 
to  one  of  following: 


Writing  Work 

Package 

Identifications 


1.  Installation 

2.  Repair 

3.  Remove  and  replace 

4.  Operation 

5.  Preventive  maintenance 

6.  Corrective  maintenance 

7.  Adjustment/alignment 

8.  Troubleshooting 

9.  Theory  of  operation 


Equipment  characteristics 


1.  Mechanical 

2.  Electrical 

3.  Electronic 

4.  Hydraulic 

5.  Pneumatic 


Book  divisions 


1.  Chapters 

2.  Sections 

3.  Subsections 


For  each  work  package,  define: 

• Data  requirements  and  sources 


• Work  package  description 

• Technical  writer  requirements 
e Estimated  page  counts 

• Validation  and  verification 
requirements 

• Quality  assurance  requirements 


Technical  Writer  Requirements 


Data  Requirements 


Estimated  Page  Counts 


Quality  Assurance 
Requirements 


In-House  TM 
Validation  and 
Verification 
Requirements 


DEFINE  VALIDATION 
AND  VERIFICATION 
REQUIREMENTS 


ESTABLISH  LIAISON  WITH 
TECHNICAL  DATA  BASE 
GENERATORS 


For  each  work  package  define: 


Determine  individual  work  package 
requirements  from: 


Items  to  be  validated  and  verified 
Sequence  of  validation  and 
verification 

Personnel  participation 


Design  engineering 


1.  Writer 

2.  Quality  assurance 

3.  Design  engineer 

4.  Customer 

5.  User 


1.  Types  of  data  available 

2.  Data  release  schedules 

3.  Writer/design  engineer  liaison 


1.  Types  of  data  available 

2.  Data  release  schedules 


Specifications  and  standards 
involved 

Time  requirements  for  validation 
and  verification 
Methods  of  vafrdaffon  and 
verification  performance 
Equipment  availability 
requirements 

Support  equipment/facilities 
requirements 


1.  Number  of  illustrations 

2.  Availability  dates 


Time  and  Equipment 

Avalfabflity 

Requirements 


Training  group 


1.  Training  data  requirements 
for  TMs 

2.  TMs  required  for  use  by 
training  group 

3.  Requirement  schedules 


For  total  equipment/system  TM 
integration  define: 


Subcontractor  TM  to  be 
validated  and  verified 
Equipment  vendor  TM  to 
be  validated  and  verified 
Items  2 thru  7 above 


Validation  and 

Verification 

Requirements 

1 

DEVELOP  VALIDATION/ 
VERIFICATION  PLAN 

TM 

Validation/ 

Based  on  requirements,  generate 

Verification 

To  TM 

validation  and  verification  plan 

for  in-house,  subcontractor  and 

* Acquisition 

equipment  vendor  developed 

Subsystem 

technical  information 

for  Review 
and  Approval 

ESTABLISH  QUALITY 
ASSURANCE  COORDINATION 


Coordinate  quality  assurance 
efforts  for: 


Technical  information  review 
In-process  review 
Validation 
verification 


3 


• Training  group 

1.  Training  data  requirements 
for  TMs 

2.  TMs  required  for  use  by 
training  group 

3.  Requirement  schedules 


1.  Design  engineering  for 
system/equipment 
description,  purpose, 
operation,  etc. 

2.  Training  for  training  TM 
requirements 

3.  Publications  for  new  or 
special  content  generation 
methods,  techniques  speci- 
fications and  standards 

Assign  writing  personnel  to 
attend  briefings  and/or  training 
sessions 


ESTABLISH  QUALITY 
ASSURANCE  COORDINATION 


Coordinate  quality  assurance 
efforts  for: 

• Technical  information  review 

• In-process  review 

• Validation 
e Verification 


Establish  detailed  TM  program 
schedule  and  milestones  based  on: 

1.  Sequence  of  work  package 
performances 

2.  Contract  start  date 

3.  Data  availability 

4.  Equipment  availability  for 

A.  Checkout  of  operator  and 
troubleshooting  procedures 

B.  Validation 

C.  verification 

5.  In-process  review  requirements 

6.  TM  delivery  dates 

7.  GFP  due  dates 

8.  Contract  schedules 

Resolve  any  schedule  conflicts  in: 

1 . Data  availability 

2.  Equipment  availability 

3.  TM  delivery  dates 


Figure  4-10.  NTIPS  Operational  Planning  Subfunction.  The  TM  eng 
work  package  and  coordinates  operational  planning  with  support  acti 
and  accuracy  of  the  actual  TM  writing  effort. 
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DEVELOP  PROGRAM  WRITER’S 
INSTRUCTIONS 


Prepare  writer's  guide  based  on: 

• Requirements 

1.  CDRLS,  TMCRs 

2.  Data  item  descriptions 

3.  Specifications 

4.  Standards 

5.  Book  Plan 

6.  Final  TM  medium 

• Contract 

1.  Statement  of  work 

2.  Exceptions  and  variations 

• Company  standards,  practices 
and  directives 

• Existing  writer's  guides  from 
previous  programs 

• GFP  writer’s  guides 

• Presentation  techniques,  readability] 
and  comprehensibility  elements  of 
specifications 


I Writing  Personnel 


ESTABLISH  SCHEDULES 

AND  MILESTONES 

• Establish  detailed  TM  program 

schedule  and  milestones  based  on: 

1. 

Sequence  of  work  package 
performances 

2. 

Contract  start  date 

3. 

Data  availability 

4. 

Equipment  availability  for 

A.  Checkout  of  operator  and 

troubleshooting  procedures 

B.  Validation 

C.  verification 

5. 

fn-process  review  requirements 

6. 

TM  delivery  dates 

7. 

GFP  due  dates 

8. 

Contract  schedules 

1 • Resolve  any  schedule  conflicts  in: 

1. 

Data  availability 

2. 

Equipment  avai'abihty 

3. 

TM  delivery  dates 

TM 

Program 

Schedule 

and 

Milestones 


NOTE: 


DEVELOP  WRITING  WORK 
PACKAGES 


For  each  work  package,  assemble 

writer  package  consisting  of: 

• Work  package  description 

• Schedule  for  work  package 
completion 

• Writer's  guide 

• TM  book  outline 

• Schedules  for  source  technical 
data  deliveries 

• Design  engineer  liaison 
representative 

• Writer  personnel  selection 


ESTABLISH  SUPPORT 
FUNCTION  COORDINATION 


Coordinate  art,  production  and 
composition  efforts  by  providing: 

• TM  format  and  style 

• Specifications 

• Standards 

• Estimated  text  and  art  page  counts 

• Schedules 

• Final  material  media 


This  diagram  represents  the  maximum  configuration. 
Tasks  shown  may  be  done  in  truncated  form  depending 
on  si?e  of  TM  activity,  size  of  TM  effort,  and  method 
of  conducting  business. 


Writing 

Work 

Packages 


. NTIPS  Operational  Planning  Subfunction.  The  TM  engineer  inatches  the  writer  to  the 
ge  and  coordinates  operational  planning  with  support  activities  to  improve  the  efficiency 
y of  the  actual  TM  writing  effort. 
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4.2.6  DESCRIPTION  OF  WRITING  FUNCTION 


The  TM  engineer  will  apply  the  modular  TM  specification  approach  to  assure  develop- 
ment of  adequate  and  accurate  TMs.  Combining  the  procuring  activity's  final  review, 
and  the  design  engineering  activity's  technical  review  of  the  TM  manuscript  with  TM 
validation  will  ensure  technical  and  operational  accuracy  as  well  as  user  effectiveness 
of  the  TM.  

TM  development  (Figure  4-11)  constitutes  the  largest  time  period  in  the 
TM  production  process.  This  is  where  the  TM  writer  becomes  involved  in  TM  produc- 
tion. All  previous  efforts,  performed  by  TM  supervisory  personnel,  were  for  the 
purpose  of  expediting  and  enhancing  the  function  of  the  TM  writer.  During  this 
phase,  previously  developed  writing  work  packages  are  used  to  generate  writer  draft 
technical  information,  which  is  reviewed  by  cognizant  TM  supervision  and  the  ac- 
tivity's quality  control  personnel.  The  reviewed  writer  draft  is  then  routed  through 
the  composition,  art,  and  production  activities,  resulting  in  the  deliverable  TM  manu- 
script. After  customer  review  and  validation,  the  TM  writer  incorporates  comments, 
verification  takes  place,  and  the  final  TM  product  is  delivered  to  the  Publishing 
Subsystem. 

Current  review  processes  and  validation,  do  not  effectively  measure  techni- 
cal manual  content  for  completeness,  technical  and  operational  accui’acy,  and  user 
effectiveness.  Validation  is  often  accomplished  at  a point  in  hardware  development 
when  engineering  changes  are  in  process.  Equipment  is  seldom  made  available  solely 
for  validation  purposes.  The  results  are  that  many  technical  manuals  are  only  par- 
tially validated  on  equipment,  while  the  remainder  are  validated  by  simulation,  or 
by  comparison  to  source  data.  The  validation  effort  concentrates  on  the  accuracy 
of  the  technical  information  presented,  but  does  not  address  specific  criteria  to  de- 
termine if  all  required  technical  information  is  present,  or  if  any  of  it  is  unnecessary. 

In  the  preliminary  concept,  the  TM  engineer  assures  the  adequacy  and  ac- 
curacy of  the  technical  manual  to  the  reviewing  agency.  The  careful  an^ysis  per- 
formed during  the  preparation  of  the  detailed  bookplan  assures  TM  completeness. 

In  addition,  because  the  bookplan  was  coordinated  with  the  using  activities,  assur- 
ance is  provided  that  it  will  be  adequate.  Once  TM  writers  are  assigned,  the  TM 
engineer  is  responsible  for  supervising  their  efforts  and  assuring  that  the  material 
they  generate  is  acceptable.  The  writers  assigned  to  each  portion  of  a manual  are 
given  the  applicable  writer  work  package,  showing  what  is  to  be  covered,  the  presen- 
tation approach  to  be  used,  and  the  depth  of  coverage  for  each  topic  assigned.  The 
system  of  modular  content  specifications  and  presentation  techniques  specifications 
will  provide  more  tutorial,  "how  to"  information  than  available  in  the  past.  Guid- 
ance for  writing  effort  management  would  be  provided  to  the  TM  engineer  by  the 
TM  Development  Guide.  (See  topic  4.2.7.) 

Combined  Reviews  of  TM  Manuscript  - A unique  feature  of  the  preliminary 
subsystem  concept  to  assure  technical  and  operational  accuracy  as  well  as  user  ef- 
fectiveness is  that  of  combining  the  procuring  activity  final  review,  technical  re- 
view, and  validation  efforts  into  a single  exercise.  The  procuring  activity's  final 
review  does  not  substitute  for  the  regular  in-process  reviews  that  are  conducted 
during  the  actual  writing  effort.  The  purpose  of  combining  reviews  is  to  resolve 
TM  problems  through  a joint  effort,  thus  permitting  all  TM  program  participants 
to  achieve  consensus  as  a body,  rather  than  posing  solutions  which  may  not  reflect 
consideration  of  other  aspects  of  the  program.  For  example,  the  training  represen- 
tative may  feel  that  the  TM  manascript  coverage  in  a specific  area  does  not  meet 
his  needs.  The  review  team  would  analyze  the  coverage  problem  not  only  from  his 
viewpoint,  but  also  from  the  viewpoint  of  the  user's  needs,  contract  requirements, 
costs,  schedules,  engineering/manufacturing  data  base  availability,  etc.  The  result- 
ing solution,  having  been  influenced  by  all  review  team  members,  should  reflect 
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agreement  in  principle  concerning  what  is  most  equitable  and  practicable  for  all 
aspects  of  the  program. 

In  order  to  implement  this  feature,  the  TM  engineer  will  form  a TM  manu- 
script review  team  consisting  of  himself  and  the  writer(s),  the  customer,  representa- 
tives from  the  user  and  training  communities,  and  design  engineering  personnel. 

If  the  system/equipment  on  which  the  TM  is  to  be  based  is  highly  complex,  represen- 
tatives from  design  engineering  will  present  a familiarization  briefing  to  the  review 
team.  This  briefing  will  cover  such  topics  as  description,  function,  and  operation 
of  the  system/equipment. 

The  team  will  review  all  nonprocedural  data  for  accuracy,  adequacy,  and 
usability.  Subsequently,  all  validation  will  be  performed  using  actual  equipment, 
and  having  all  team  members  in  attendance.  The  TM  engineer  will  coordinate  the 
validation  of  narrative  material  accuracy  with  design  engineering  and  the  validation 
of  procedural  material  on  the  equipment.  Design  engineering  participation  is  critical 
at  this  time  because  they  can  assure  the  TM  engineer,  as  a result  of  their  review, 
that  the  latest  design  changes  have  been  incorporated  in  the  TM  nanuscript  or  iden- 
tify which  areas  require  rework  to  pick  up  unincorporated  design  changes.  Additional 
validation  is  provided  by  the  in-house  activities  that  use  the  TM  draft  manuscript 
for  assembly,  test,  checkout,  and  integration.  During  verification,  the  TM  engineer 
will  provide  the  support  requested  by  the  reviewing  agency. 

A post-program  review  is  established  for  the  purpose  of  evaluating  each 
recently  completed  TM  program  to  identify  any  future  improvements  in  the  develop- 
ment. The  post-program  review  team  is  comprised  of  the  TM  engineer  and  his  coun- 
terpart at  the  TM  Acquisition  Subsystem  as  well  as  representatives  from  the  train- 
ing, logistic  analysis,  quality  assurance,  and  design  engineering  activities.  This  team 
is  charged  with  the  collection  and  analysis  of  all  historical  data  associated  with 
TM  development  programs.  Included  are  all  problems  encountered,  from  TM  esti- 
mating through  final  delivery,  their  causes  and  solutions,  as  well  as  user  and  cus- 
tomer comments.  Particular  emphasis  is  placed  upon  identifying  those  problems 
that  occur  repeatedly  (or  are  common  to  several  programs),  and  evaluating  the  solu- 
tions that  were  applied  in  each  case.  Typical  of  these  problems  are:  (1)  scheduling 
of  TM  writer  "hands-on"  equipment  and  validation  times,  (2)  conflicts  in  TM  specifi- 
cations and  other  contractual  documents,  (3)  development  of  TM  outlines  during 
TM  planning,  (4)  implementation  of  TM  planning  during  TM  development,  (5) 
engineering/manufacturing  and/or  LSA  data  base  inaccuracies  and  unavailabilities, 
and  (6)  incomplete  understanding  between  TM  acquisition  activity  and  the  content 
generator  as  related  to  specifications  and  other  contractual  documents  related  to 
the  TM  procurement.  As  solutions  are  evaluated  and  one  has  been  determined  to 
be  the  most  effective  means  of  solving  the  common  problem,  it  becomes  a recom- 
mended policy/procedure  applicable  to  future  TM  efforts. 

Writing  Function  Alternatives  - One  alternative  is  to  use  design  engineers 
to  write  the  technical  manuals.  This  alternative  capitalizes  on  the  technical  knowl- 
edge of  the  equipment  design  engineers.  Each  design  engineer  would  be  selected  for 
a specific  technical  writing  assignment  based  on  his  equipment  knowledge  rather 
than  on  his  known  writing  skill.  The  lack  of  writing  skill  is  compensated  for  by  using 
lower-priced  technical  writing  personnel  to  edit  and  publish  the  TMs. 

A second  alternative  is  to  automate  suitable  portions  of  the  writing  process. 

In  this  alternative,  the  use  of  automation  in  the  transformation  of  the  engineering/ 
manufacturing  and/or  LSA  data  bases  to  TMs  not  only  provides  a more  efficient 
transformation,  but  the  transformation  process  is  more  responsive  to  a wide  variety 
of  TM  presentation  techniques.  The  keyboard  on  a three-dimensional  interactive 
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4.2.6  DESCRIPTION  OF  WRITING  FUNCTION  (Continued) 


graphic  display  terminal  provides  the  means  for  entering  text  or  tabular  information 
into  a computer,  withdrawing  it  for  update  with  no  rehandling  of  unchanged  portions, 
or  making  it  available  for  use  at  another  terminal.  Drawings  can  be  entered  into 
a computer  by  a combination  of  keyboarding  and  light-penciling  on  a CRT  face  at 
the  same  terminal,  by  an  X-Y  plotter  through  a digital  processor,  or  by  an  optical 
scanner.  Text  information  and  drawings  stored  in  digital  form  can  be  displayed 
on  the  terminal  and  hard  copies  (paper)  obtained  using  a line  printer  for  text  and 
an  X-Y  plotter  for  drawings. 

As  an  example,  the  content  generator  traditionally  depends  upon  ortho- 
graphic mechanical  assembly  drawings  as  well  as  access  to  the  hardware  for  the 
development  of  removal  and  replacement  procedures.  However,  in  the  automated 
system,  he  would  use  his  interactive  graphic  display  terminal  to  call  up  the  specific 
drawing  that  contains  the  mechanical  assembly  information  he  needs  to  develop 
the  procedure.  This  information  is  available  to  his  terminal  through  the  terminal's 
interface  with  the  computer  dedicated  to  the  development  and  storage  of  the 
engineering/manufacturing  data  base.  Using  the  keyboard  and  light-pen  features 
of  his  terminal,  he  reworks  the  drawing  until  it  conveys  the  information  necessary 
to  support  the  procedure.  Once  the  drawing  rework  is  completed,  he  commands 
it  to  be  stored  in  the  computer  dedicated  to  the  TIVI  development. 

Automation  offers  the  writer  various  methods  and  aids  in  the  development 
of  text  material.  He  can  use  the  terminal  to  copyfit  blocks  of  descriptive  text  to 
functional  flow  diagrams  or  make  callouts  fit  the  available  space  on  schematics. 

He  first  calls  up  and  displays  the  diagram,  then  uses  the  keyboard  to  add  the  text 
or  callouts  in  the  selected  position  on  the  diagram.  In  developing  straight  text  he 
can  use  the  terminal  to  ensure  he  is  maintaining  the  correct  readability  level.  He 
enters  the  text  in  question  into  the  terminal  and  instructs  the  terminal  to  evaluate 
the  reading  level.  The  terminal's  associated  computer  checks  sentence  length  and 
word  length  against  internally  set  standards  and  displays  the  results  to  the  writer. 

He  then  can  rework  the  text  if  necessary  to  bring  it  into  conformance.  The  termi- 
nal's ability  to  present  vocabulary  assistance  when  requested  enables  the  writer 
to  prepare  consistent  and  clear  text.  The  terminal  also  offers  quick  information 
retrieval  from  an  automated  logistics  support  analysis  data  base.  Maintenance  data 
such  as  a removal  and  replacement  procedure  can  be  called  up,  reworked  to  meet 
the  TM  requirements  for  format  and  style,  and  then  stored  in  the  computer  dedi- 
cated to  TM  development. 

A third  alternative  employs  writing  staff  assistance  in  the  development 
of  the  engineering/manufacturing  and/or  LSA  data  bases.  The  primary  objective 
of  this  alternative  is  to  reduce  the  writing  staff's  required  familiarization  time  for 
new  systems/equipments  and  their  associated  data  bases.  Unfamiliarity  with  new 
hardware  and/or  data  impedes  a writer's  initial  productivity.  This  can  be  a particu- 
lar detriment  to  TM  programs  having  relatively  short  development  cycles.  As  an 
example  of  employing  this  alternative,  a group  of  writers  would  be  assigned  to  the 
design  engineering  activity.  They  would  prepare  items  of  the  engineering/ 
manufacturing  data  base  (such  as  equipment  descriptions  and  functional  flow  dia- 
grams) under  the  direction  of  the  design  engineer.  Also,  in  the  LSA  data  base,  the 
writers  could  assist  in  the  analysis  of  maintenance  functions  to  determine  the  type 
of  procedure  (removal,  replacement,  adjustment,  etc.)  required  and  types  of  tools, 
test  equipment,  and  facilities  needed  to  support  the  procedure.  Becoming  familiar 
with  this  type  of  information  prior  to  the  start  of  the  actual  writing  enables  the 
writers  to  be  more  productive. 
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DRAFT  TEXT  AND  ART 
DEVELOPMENT 


TECHNICAL  AND  EDITORIAL 
REVIEW 


Writing  supervisor  or  lead  writer 
briefs  writer  on  work  package, 
writing  duties  and  schedules 


For  eacf)  work  package  draft 
material,  lead  writer  performs: 


Writer  develops; 


1.  Data  base 

A.  Gathers  data 

B.  Analyzes  data 

C.  Interrelates  with  data 
base  generators 

2.  Text  and  illustrations 

A.  Analyzes  specifications 
and  standards 

B.  TMCRs 

C.  Reviews  bookpian 
requirements 

D.  Schedules  work 

E.  Uses  writer's  guide 

F Observes  hardware 


\Not\  Package 
Draf  Material 


Technical  ed:*.  based  on: 

A.  Data  base 

B.  Speci fications,  standards, 
data  Item  descriptions 

C.  TMCRs 

D.  Maintenance  concept 

E.  Statement  of  work 
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A.  Specifications,  standards, 
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C.  Statement  of  work  requirement 

D.  Training  TM  requirements 
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Review  team  formed  by  TM 
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engineer  and  Q.A.  engineer 
perform  informal  in*process 
reviews  and  documents  all 
problem  areas  and  their  solutions 


Customer  performs  IPR 


4.  Format,  style,  presentation 
techniques,  readability  and 
comprehensibility  edit  based  on: 

A.  Specificat  ons,  standards, 
data  Item  descriptions 

B.  TMCRs 

C.  Statement  of  work 

D.  Writer's  guide 

E.  Readability  and 
comprehensibility  tests 
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Material 
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TM  REVIEW  AND 
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FINALIZE  TM  MANUSCRIPT 


TM  engineer  forms  technical 
review  and  validation  team 
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Manuscript  with 
Comments 


1.  Customer 

2.  user 

3.  TM  engineer 

4.  Writer 

5.  Design  engineer 

6.  Training  instructor 

7.  Q.A.  engineer 


Composition; 

1.  Typist  incorporates  all  text 
changes  into  typed  copy 

2.  Proofs  typed  copy 
Illustration: 

1.  Artist  incorporates  all  art 
Changes  into  illustrations 

2.  Performs  art  check 


Team  reviews  TM  nonprocedural 
data  for: 


1.  Assembles  and  co'lates  typed 
copy  and  final  art  into  TM 
camera-reads  reproducible  copy 
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copy 
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printed  cop 
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1.  Conformance  to  specifications, 
standards,  data  item  descrip- 
tions, training  TM  requirements. 
Statement  of  work  and  TMCRs 


SUBCONTRACTOR  DEVELOPED 
TM  ACCEPTANCE 


Technical  accuracy 


3.  Maintenance  concept  being 
satisfactorily  implemented 


iiuring  technical  m'orma*  on 
development,  contractor  team 
made  up  of  TM  and  Q.A. engineers: 


4.  Adequate  technical  coverage 


Team  performs  validation  on  all  TM 
procedural  data  by  actual  perform- 
ance on  system/equipment 
Team  documents  all  problem  areas 
and  their  solutions 


Subcontractor  T M 


1.  Monitor  progress 

2.  In  conjunction  with  user, 
observe  validation 

3.  Check  conformance  to  sub- 
contract requirements,  spec- 
ifications, standards,  main- 
tenance concept  and  quality 
assurance  requirements 

Tentatively  accepts  TM  contin- 
gent upon  customer/contractor 
verification  results 


Equipment  Vendor  TM 


editowial 


WORK  PACKAGE  INTEGRATION 
AND  TM  REVIEW 


TM  DRAFT  M ATE R I AL  QU AH T Y 
ASSURANCE  CHECK 


• Lead  writer: 

1.  Assemblies  all  work  package  draft 
material  in  proper  sequence  as 

Reviewed  Work  defined  by  book  outline  into 

Package  Draft  complete  TM 

2.  Reviews  complete  TM  for 
reference  accuracy , complete- 
ness and  overall  depth  of 
coverage 

• Review  team  formed  by  TM 
engineer,  writer,  trainer,  design 
ei^gineer  and  Q.A.  engineer 
performs  informal  in-process 
review 

• Customer  performs  IPR 


Complete  ! M 
Draft  Material 


Quality  assurance  engineer  reviews 
TM  draft  material  for; 

1.  Accuracy 

2.  Readability  and 
comprehensibility 

3.  Clarity 

4.  Consistency 

5.  Conformance  to: 

A.  Specifications,  standards, 
data  Item  descriptions 

B.  TMCRs 

C.  Statement  of  work 
Lead  writer  resolves  any  Q.A. 
comments 


Q.A.  Checked 
Complete  T M 
Draft  Material 


Review  team  formed  by  TM 
engineer,  writer,  trainer,  design 
engineer  and  Q.A.  engineer 
perform  informal  in-process 
reviews  and  documents  all 
problem  areas  and  their  solutions 

Customer  performs  IPR 


FINALIZE  TM  MANUSCRIPT 


2.  Obtains  final  manuscript  printed 
copy 

Quality  assurance 

1.  Reviews  TM  camera-ready 
reproducible  copy  for  accu'^acy 
of  comment  incorporation 

2.  Reviews  TM  final  manuscript 
printed  copies  for  quality  and 
completeness 

3.  Assures  TM  final  manuscript 
printed  copy  deliveries  are  made 
in  accordance  with  CDRLs/ 

TM(,RS 


Validated  TM  Final  Manuscript 


SUBCONTRACTOR  DEVELOPED 
TM  ACCEPTANCE 


During  tecrmical  mtormation 
development,  contractor  team 
made  up  of  TM  and  Q.A.  engineers: 

1.  Monitor  progress 

2.  In  conjunction  with  user, 
observe  validation 

3.  Check  conformance  to  sub- 
contract requirements,  spec- 
ifications, standards,  main- 
tenance concept  and  quality 
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» Tentatively  accepts  TM  contin- 
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verification  results 
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Validated  Subcontracted  TM 


EQUIPMENT  VENDOR  DEVELOPED 
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1. 
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A.  Style  and  format 

B.  Depth  of  content 
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ON-SITE  TM  VERIFICATION 
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TM  MANUSCRIPT  PREPARATION 

• Composition: 

• Writing: 

1.  Typist  converts  text  draft 

Lead  writer  resolves  any  compo- 

material  into  typed  copy 

Sitlon,  illustration  or  production 

2.  Pioofs  typed  copy 

problems 

• Illustration: 

• Quality  assurance: 

1.  Artist  converts  art  draft 

1.  Reviews  TM  camera-ready 
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2.  Performs  art  check 
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printed  copies  for  quality 
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copies 
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rM  FINAL  MATERIAL  PREPARATION 
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applicable  comments  into  TM 
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1.  Typist  incorporates  all  text  changes 

comment  incorporation 
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into  final  art 
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Final  TM 
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To  Publishing 
Subsystem 


This  diagram  represents  the  maximum  configuration.  Tasks  shown  may 
be  done  In  truncated  form  depending  on  size  of  TM  activity,  size  of  TM 
effort,  and  method  of  conducting  business.  TM  production  efforts  are 
shown  for  continuity  purposes  only. 


Figure  4-11.  NTIPS  Preliminary  Concept  for  Writing.  The  TM  engineer  provides  single-point  guidance, 
supervision  and  coordination  during  TM  development  to  assure  accurate  and  adequate  TMs  are  devel- 
oped. Combining  technical  reviews  and  the  procuring  activity’s  final  reviews  with  validation  assures 
accurate  and  adequate  TMs  that  will  meet  u.ser  needs. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  - Content  Generation  Subsystem 

4.2.7  - PURPOSE  AND  DESCRIPTION  OF  THE  TM  DEVELOPMENT  GUIDE 


A TM  Development  Guide  would  support  the  TM  engineer  in  his  planning  for  the  Develop- 
ment of  technical  information.  The  Guide  would  supply  the  necessary  instructions  and 
guidance  for  the  TM  engineer  to  accomplish  the  tasks  associated  with  estimating,  plan- 
ning, and  developing  technical  information. 


In  current  practice,  requirements  for  estimating,  as  well  as  product  plan- 
ning and  writing,  for  a specific  TM  acquisition  are  contained  in  the  request  for  esti- 
mate and  contractual  documents  such  as  statement  of  work,  specifications  and  stand- 
ards. These  requirements  cover  all  facets  of  TM  development,  including  the  TM 
type,  style,  format,  content,  maintenance  philosophy,  depth  of  coverage,  method 
of  validation,  final  medium,  etc.  However,  no  instruction  or  guidance  is  provided 
to  the  TM  engineer  on  how  and  when  to  plan,  initiate,  and  supervise  the  efforts  that 
are  necessary  to  accomplish  the  tasks  associated  with  estimating,  planning,  and 
writing  the  TM.  He  must  rely  on  his  technical  and  managerial  experience,  and  his 
knowledge  gained  from  previous  programs.  This  limits  his  performance  effective- 
ness on  a TM  program  with  which  he  is  not  totally  familiar.  For  example,  a problem 
encountered  by  the  TM  engineer  such  as  inconsistent  use  of  nomenclature  in  text 
would  place  additional  time  requirements  on  his  already  busy  schedule.  He  would 
have  to  suspend  his  regular  activities  while  he  identifies  the  cause  which  may  be 
an  unclear  specification  requirement  or  the  lack  of  a standardized  nomenclature/ 
common  names  list.  Then  he  has  to  develop  a workable  solution  such  as  obtaining 
clarification  from  the  TM  procuring  activity,  or  preparing  the  necessary  list.  But 
his  solution  may  develop  into  another  and  even  more  difficult  problem  later  in  the 
TM  development  because  he  cannot  completely  visualize  the  impact  of  his  solution 
until  completion  of  the  TM  final  product.  In  the  case  of  the  nomenclature/common 
names  list,  the  use  of  common  names  simplifies  the  text  but  eliminates  part  number 
references,  forcing  the  user  to  spend  additional  time  locating  the  nomenclature/ 
common  names  list  to  obtain  the  part  number.  This  reduces  TM  usability. 

The  TM  Development  Guide  (Table  4-9)  would  be  designed  to  meet  the 
detailed  planning  and  management  needs  of  the  TM  engineer  for  any  TM  acquisition 
program.  This  guidesupplements  instructions  contained  in  the  request  for  estimate 
and  contractual  documents  with  detailed  instructions  and  guidance  on  how  and  when 
to  plan  and  supervise  the  TM  development  activity's  efforts  in  the  preparation  of 
TM  estimates,  product  and  operational  plans  and  TM  manuscripts.  The  instructions 
would  consist  of  step-by-step  procedures  detailing  how  and  when  to  plan,  initiate, 
and  accomplish  in  the  most  efficient  manner  the  tasks  for  each  function  described 
in  the  Content  Generation  Subsystem  preliminary  concept. 

The  guide  would  provide  instructions  for  the  TM  engineer  on  how  to:  (1) 
estimate  the  number  of  personnel  and  define  the  specialty  skills  that  are  required 
for  a specific  TM  task,  (2)  establish  working  schedules,  (3)  establish  a status  report 
system  and  develop  reporting  procedures,  and  (4)  monitor  and  evaluate  the  progress 
and  performance  of  each  task.  The  guide  would  also  tell  the  TM  engineer  when 
to:  U)  establish  interrelationships  with  activities  outside  of  the  Content  Genera- 
tion Subsystem  and  the  NTIP  System,  (2)  initiate  specific  task  efforts,  and  (3)  est- 
ablish coordination  with  TM  support  activities  (i.e.,  composition,  illustration,  pro- 
duction and  quality  assurance).  In  addition,  the  guide  would  identify  possible  problem 
areas  in  TM  development  and  provide  one  or  more  suggested  solutions.  For  example, 
slippage  of  the  equipment  availability  for  the  TM  manuscript  validation  is  a big  pro- 
blem in  content  generation.  Possible  solutions  are  to:  (1)  perform  validation  on  a 
three-shift  (24-hour)  schedule  when  the  equipment  becomes  available,  (2)  perform 
normal  (single-shift)  validation  when  the  equipment  becomes  available  (with  resultant 
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late  or  delayed  TM  delivery),  or  (3)  perform  incremental  validations  as  portions  of 
equipment  become  available.  The  guide  also  would  provide  the  TiVI  engineer  with 
examples,  where  necessary,  to  clearly  illustrate  a point  or  instruction.  Finally,  the 
guide  would  remind  the  TM  engineer  that  he  should  keep  abreast  of  new  and  innova- 
tive TM  development  and  presentation  Techniques.  Because  of  his  close  involvement 
ina  specific  TM  program,  the  TM  engineer  becomes  aware  of  any  peculiar  presenta- 
tion problems  associated  with  new  or  advanced  hardware  technologies  and/or  main- 
tenance approaches  before  the  NTIPS  T.Vl  acquisition  activity  becomes  aware  of  it. 
He  designs  and  develops  a solution  or  evaluates  the  new  techniques  for  their  impact 
and  application  on  the  special  problem.  If  his  solution  or  new  technique  solves  the 
problem,  he  would  then  submit  his  evaluation  and  recommendations  to  the  NTIPS  TM 
acquisition  activity  for  review  and  approval  prior  to  initiating  action  to  incorporate 
the  technique. 

The  NTIP  System  is  the  responsible  organization  for  the  design  and  develop- 
ment of  the  TM  Development  Guide.  The  guide  would  incorporate  basic  management 
principles,  as  applied  to  TM  development,  to  guide  the  TM  engineer  in  the  perform- 
ance of  his  duties.  It  would  be  based  on  and  developed  from  the  experience  and 
knowledge  gained  through  the  research  and  evaluation  of  past  and  present  TM  devel- 
opment operations  and  the  development  of  the  NTIP  System  for  the  Navy.  To  keep 
the  guide  current,  user-proposed  additions  and  recommended  changes,  and  new  and 
innovative  TM  development  and  presentation  techniques  developed  outside  the  Navy 
as  well  as  the  results  of  the  NTIP  System  continuing  research  effort  would  be  re- 
viewed and  evaluated  by  the  guide  development  activity  within  NTIPS.  Changes  that 
improve  the  guide's  accuracy,  use,  and  applicability  would  be  incorporated  in  the 
most  expeditious  manner  to  insure  currency  of  all  guides  in  use. 

TABLE  4-9.  TM  DEVELOPMENT  GUIDE  AS  AN  AID  TO  TM  ENGINEER 

Purpose  • Support  TM  engineer  in  planning,  initiating,  supervising, 

and  monitoring  of  TM  estimating,  planning  and  writing 
efforts. 

• Supplement  directions  contained  in  requests  for  estimates 
and  contractual  documents. 

Content  • Step-by-step  procedures  for  how  and  when  to  perform  tasks 

associated  with  TM  estimating,  product  and  operational 
planning,  and  writing. 

• Examples  of  types  of  problems  that  may  be  encountered 
and  suggested  solutions  that  have  been  proven  valid  on 
previous  TM  programs. 

• Reminders  for  the  TM  engineer  to  keep  abreast  of  new 
and  innovative  TM  development  and  presentation  tech- 
niques for  possible  application  to  his  program. 

Development  • Designed  and  prepared  by  NTIP  System 

• Based  on  basic  management  principles,  experience  and 
knowledge  gained  from  research  of  present  TM  develop- 
ment systems,  and  development  of  NTIP  System  for  Navy. 

• Maintained  current  by  incorporating  user-recommended 
changes  and  results  of  on-going  NTIPS  research. 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  — Content  Generation  Subsystem 

4.2.8  NTIPS  TM  WRITERS  GUIDE 


The  NTIPS  TM  writers  ^ide  will  be  used  to  both  instruct  and  motivate  TM  engineers  and 
TM  writers  regarding  the  importance  of  their  role  in  developing  the  new  generation 
of  User-Matched  TMs. 

The  NTIPS  writers  guide  would  be  a concise,  informative  tour  through  the 
world  of  what's  good  and  bad  about  TMs,  especially  how  to  create  the  TM  of  today's 
Navy  for  real  users  in  the  field.  It  would  be  written  entirely  from  the  viewpoint 
of  the  junior  TM  writer  who  needs  an  overall  view  but  also  wants  fast  access  to 
useful  tools  and  hints  (see  Figure  4-12). 

Introduction  to  NTIPS  - The  first  chapter  would  introduce  the  objectives 
of  NTIPS  and  describe  the  most  important  operations  of  the  system  and  how  they 
affect  writing  assignments.  It  would  include  a synopsis  of  the  interactions  of  the 
NTIPS  elements  from  TM  program  inception  to  delivery  of  the  finished  TM  product 
to  the  user.  To  develop  the  TM  writer's  appreciation  of  NTIPS,  the  description  will 
include  the  "why's"  as  well  as  the  "how's".  In  this  chapter  of  the  guide  and  those 
that  follow,  every  effort  will  be  made  to  avoid  the  type  of  formal,  laborious  presen- 
tation which  would  discourage  wide  readership.  Instead,  the  guide  will  be  developed 
in  an  informal,  easy-to-read  style  employing  devices  such  as  cartoons  to  motivate 
the  reader. 

Introduction  to  the  Specifications  System.  If  the  NTIPS  preliminary  system 
concept  of  modular  specifications  were  adopted,  it  would  represent  a major  change 
to  the  current  Navy  TM  specification  structure,  and  to  the  TM  writers  who  currently 
use  these  specifications.  This  chapter  of  the  guide  would  fulfill  the  need  for  edu- 
cating TM  engineers  and  writers  to  the  new  specification  structure.  The  benefits 
of  specification  modularity,  its  relationship  to  the  user-data  match  model,  and  the 
application  of  the  modules  in  TM  development  will  be  described.  The  unique  tutorial 
or  how-to  aspects  of  the  new  modular  specifications  would  be  stressed.  The  writer 
would  be  motivated  to  perceive  the  specification  system  as  practical  aids  to  his 
work  and  professional  growth. 

Presentation  Techniques  - This  chapter  will  introduce  the  TM  writer  to  the 
different  media  and  presentation  techniques  which  NTIPS  will  employ  to  satisfy 
all  special  user  requirements.  A brief  nontechnical  description  of  the  user-data 
match  model  will  explain  how  presentation  techniques  for  specific  procurements 
are  selected.  Some  examples  will  illustrate  the  kind  of  problems  that  led  to  the 
development  of  the  model  and  the  NTIPS  presentation  techniques  and  systems. 

The  presentation  techniques  specification  modules  will  be  introduced  and  explained. 
For  example  this  would  cover  NAVSEA's  and  NAVELEX's  Functionally  Oriented 
Maintenance  Manuals  (FOMM),  NAVAlR's  Work  Package  technique,  the  Air  Force's 
Job  Performance  Aids  (JPA)  technique,  the  Army's  Improved  Technical  Documenta- 
tion and  Training  (ITDT)  technique,  and  NSA's  Diagram  Oriented  Documentation 
System  (DIODS).  The  application  of  these  specification  modules,  as  well  as  their 
relationship  to  other  module  categories  also  will  be  covered. 

Guide  to  Clear  TM  Writing  - Over  the  years,  many  Clear  Writing  style  guides 
have  be^n  prepared  for  business  and  military  use.  A good  example  of  these  is  the 
Guide  for  Air  Force  Writing  (AF  Pamphlet  13-2)  which  covers  basic  principles  in 
logical  organization,  choice  of  appropriate  words,  keeping  sentence  structure  simple, 
using  transitions,  effective  use  of  illustrations,  etc.  In  recent  years  a new  kind  of 
writing  guide  strictly  for  the  TM  writer  has  appeared  which  covers  these  basic  prin- 
ciples but  also  treats  of  the  specific  problems  in  building  more  comprehensible  main- 
tenance and  operating  manuals.  Good  examples  of  this  are  NAVSEA's  "Requirements 
and  Criteria  for  Improving  Reading  Comprehension  of  Technical  Manuals"  (Post 
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and  Price,  1974),  NAVAIH"s  "TM  Preparation  Guide  for  Writers,  Editors  and  Illus- 
trators" (NAVAIR  00-25-700),  and  the  Army's  VIIL-M-63038  (TVl),  especially  Vol  3, 
"Technical  Writing  Style  Guide"  (MIL-HDBK-63038-2).  Some  of  these  guides,  how- 
ever, are  prepared  for  a partieular  T\1  presentation  system;  some  lack  concision 
in  coverage  of  their  material. 

What  is  needed  for  NTIPS  is  an  introduction  to  the  available  guides  for  the 
now  r.M  writer,  followed  by  a very  concise  compilation  of  the  best  ideas  from  each. 
This  compilation  would  cover  general  writing  hints  (active  vs.  passive  construction, 
avoiding  nominalizations,  concrete  vs.  abstract  words,  parallelism,  sentence  variety, 
spelling  out  acronyms,  defining  terms,  paragraph  unity,  topic  sentences,  continuity 
devices,  giving  examples,  using  redundance,  etc.).  It  would  also  cover  the  special- 
ties of  writing  TMs  (styles  appropriate  to  the  main  TM  sections,  getting  the  most 
out  of  text  and  figure  units,  limiting  excessive  narration,  writing  proceduralized 
material,  developing  troubleshooting  data,  layout  of  text  and  figures,  special  treat- 
ments of  illustrations,  etc.).  This  material  would  stress  the  universal  techniques 
and  basic  human  factors  principles  that  apply  to  all  types  of  T\ls  (e.g.,  correct  use 
of  foldouts,  typography  hints,  highlighting,  consistency,  minimizing  cross  references, 
principles  of  graphic  clearity,  etc.).  It  would  avoid  duplicating  the  presentation 
techniques  and  systems  specifictions,  but  would  show  how  their  ideas  (such  as  work 
packaging,  or  putting  text  into  diagrams,  or  pyramiding  the  systems  diagrams,  etc.) 
are  useful  in  a variety  of  situations. 

Readability  - Readability,  in  the  sense  of  a quantitative  technique  for  pre- 
dicting comprehension  from  lexical  measurements,  is  still  a new  subject  to  many 
TM  writers.  The  NTIPS  guide  would  undertake  to  introduce  the  TM  writer  to  this 
technique,  explain  its  importance  to  the  user  in  the  field,  and  motivate  the  writer 
to  apply  the  assessment  process  diligently.  But  even  more  important  is  to  help  the 
writer  internalize  the  writing  skills  and  style  changes  that  are  necessary  to  produce 
more  readable  writing  in  the  first  draft.  To  accomplish  this,  it  is  not  sufficient 
to  merely  call  for  shorter  words  and  sentences,  clearer  thinking,  etc,  as  in  the  conven- 
tional "clear  writing"  guide.  Guides  which  recognize  the  need  for  more  practical 
instructions  for  the  TM  writer  unfamiliar  with  readable  writing  include  Klare's  "A 
Manual  for  Readable  Writing,"  1S75  and  Kern's,  et  al,  "Guide  for  Development  of 
Army  Training  Literature,"  1976. 

The  NTIPS  guide  would  introduce  the  TM  writer  to  these  resources,  and 
review  the  known  do's  and  don'ts  of  readable  writing.  Of  particular  value  would 
be  specific  guidance  in  making  readability  revisions  on  a step-by-step  basis.  The 
NTIPS  guide  would  attempt  to  list  the  distinct  mechanism  which  can  be  invoked 

Figure  4-12.  Approach  to  TM  Writers  Guide. 

1.  Introduction  to  NTIPS 

2.  Introduction  to  the  Specifications  System 

3.  Presentation  Techniques 

4.  Guide  to  TM  Writing 

5.  Readability 

6.  Comprehensibility 


7.  Vocabulary  Controls 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.2  - Content  Generation  Subsystem 

4.2.8  NTIPS  TM  WRITERS  GUIDE  (Continued) 


during  a revision  to  reduce  RGL  in  a once  written  text,  such  as  methods  of 
substituting  words,  deleting  words,  dividing  sentences,  etc.  When  the  writer  learns 
these  distinct  mechanisms,  as  if  he  were  an  editor,  then  he  will  be  in  a position  to 
internalize  them  as  part  of  his  repertoire  of  basic  writing  style  options. 

He  would  also  learn  how  combinations  of  these  mechanisms  are  appropri- 
ately selected  to  recast  a text  to  various  required  levels  so  that  ultimately  he  could 
write  to  a given  level  through  unconscious  adjustments.  The  NTIPS  guide  would 
attempt  to  provide  a definitive  treatment  of  specific  mechanisms,  including  lexical 
methods  of  finding  word  substitutes,  determining  words  to  delete,  recasting  to  bridge 
over  deletions,  breaking  up  adjective  clusters,  spotting  needless  circumlocations, 
avoiding  nominalizations,  guides  for  replacing  technical  with  nontechnical  words, 
deleting  words  by  explaining  them,  etc.  Syntactic  mechanisms  that  would  be  defined 
include  methods  of  dividing  sentences  on  semicolons,  conjunctions,  relative  clauses, 
verb  phrases,  prepositional  phrases,  etc.  Rhitorical  revisions  having  quantitative 
impacts,  such  as  how  to  distinguish  unnecessary  information  and  "details",  would 
also  be  addressed. 

Most  of  us  learn  how  to  write  in  school  f,radually  accumulating  more 
and  more  structures  into  more  complicated  senitfice  patterns,  using  various  gram- 
matical transforms  to  enfold  and  embed  the  pieces,  all  more  or  less  unconsciously. 
The  proposed  approach  would  reverse  this  process,  teaching  the  TM  writer  to  con- 
sciously manipulate  his  transforms  in  both  directions,  especially  to  "disassemble" 
his  habitual  thinking  patterns  into  smaller  progressive  disclosures. 

Implicit  in  this  approach  is  the  belief  that  a direct  "frontal"  attack  on  the 
readability  requirement,  by  "mechanically"  reducing  word  length  and  sentence  length, 
is  a salutary  and  effective  means  of  improving  the  comprehension  of  the  reader. 

It  is  sometimes  argued  to  the  contrary  that  one  cannot  write  more  readably  by  "jug- 
gling the  measurement"  factors  directly,  that  the  writer  must  conceptually  rethink 
his  story  from  a lower  level  and  then  recheck  his  results  from  the  readability  view- 
point later  on,  etc.  But  work  at  Hughes  suggests  that  this  fear  of  "cheating"  is  un- 
founded. In  case  after  case,  it  has  been  shown  that  a direct  reduction  of  big  words 
and  long  sentences  (without  regard  for  the  niceties  of  continuity,  and  "tone",  but 
leaving  technical  vocabulary  more  or  less  untouched)  will  produce  sizable  improve- 
ments in  both  readability  and  comprehensibility.  Hence,  the  "learn  by  editing"  ap- 
proach, where  the  TM  writer  internalizes  a set  of  simple  stylistic  mechanisms,  could 
be  expected  to  provide  meaningful  results  quickly  under  controllable  training  con- 
ditions. 

Comprehensibility  - Similar  Guidelines  are  also  needed  for  the  comprehen- 
sibility factors  that  have  been  or  can  be  quantified.  The  NTIPS  writers  guide  would 
introduce  the  TM  writer  to  existing  and  proven  systems,  such  as  the  NAVAIR  Com- 
prehensibility Assurance  Criteria  (NAVAIR  00-25-700)  for  Work  Package  TMs,  which 
covers  many  specific  mechanisms  under  Access,  Nonverbal  Organization,  "Chunk- 
ing", Procedures,  Consistency,  Readability,  Legibility,  Pictorial  Illustrations,  Sche- 
matics, Wiring  Diagrams,  Functional  Diagrams,  and  Tables.  Quantitative  measures 
to  control  the  comprehensibility  of  graphics  would  be  an  important  part  of  this  guide. 

In  addition  to  quantitative  criteria  for  readability  and  comprehensibility, 
the  TM  writer  would  be  introduced  to  the  notion  of  vocabulary  aids  and  controls. 

The  most  important  vocabulary  aid  would  be  big  word  substitution  glossaries  organ- 
ized for  the  technical  vocabulary  of  various  Navy  Ratings  as  well  as  for  the  non- 
technical TM  vocabulary  in  general.  It  is  surprisingly  hard  to  find  acceptable  syn- 
onyms for  big  words,  even  nontechnical  big  words.  These  glossaries  would  be  of 
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great  assistance  in  applying  the  readability  discipline  and  could  be  automated  so 
that  the  big  words  and  their  alternatives  are  listed  out  for  the  TV!  writer  along  with 
his  readability  assessment.  A considerable  investment  would  be  required  to  build 
these  glossaries,  because  of  the  tedious  research  and  sticky  semantics  questions 
involved,  but  it  would  be  a very  wise  investment  considering  the  plight  of  both  the 
user  and  lAl  writer  if  help  is  not  made  available. 

Vocabulary  Controls  - One  aspect  of  vocabulary  controls  that  has  received 
considerable  attention  has  been  the  area  of  verb  usage.  One  example  is  JV11J.-J-83302 
(USAF),  which  provides  a fairly  extensive  list  of  verbs  to  be  used  in  the  develop- 
ment of  textual  material  for  technical  manuals.  Included  in  this  list  are  (for  each 
verb):  the  definition,  examples  of  the  use  of  the  word,  a preference  rank  (indicat- 
ing the  standing  of  that  verb  compared  to  others  with  the  same,  or  similar  meaning), 
and  synonyms  (listed  in  order  of  preference). 

This  type  of  information  should  be  incorporated  into  the  specifications 
governing  each  procurement.  In  addition,  a list  of  nouns  should  be  developed  for 
inclusion  in  TM  specifications  that  contains  information  identical  to  that  contained 
in  the  verb  list.  In  particular,  this  list  should  contain  generic  nouns  (i.e.,  those  nouns 
that  relate  to  a group  or  class  of  items,  rather  than  to  a specific  item).  Noun  and 
verb  lists  developed  for  inclusion  in  TM  specifications  could  serve  a dual  purpose. 

That  is,  they  could  also  be  used  as  supplemental  data  in  support  of  TM  writers  guides. 
These  lists  could  (with  some  revision/expansion)  serve  as  a glossary  of  terms  for 
use  by  the  writer  during  the  composition  of  text  for  the  TM. 

Currently,  many  vocabulary  guides  exist  throughout  the  military  and  industry, 
a good  example  being  found  in  the  Army  guide,  MlL-M-63038  (TM).  Also,  a guide 
that  is  becoming  increasingly  popular  in  commercial  applications  is  the  Basic  800 
system  developed  by  Smart  Communications,  Inc.  The  TM  writer  should  be  introduced 
to  these  resources,  and  they  should  also  be  analyzed  as  inputs  for  standard  vocabu- 
lary guides  and  preferred  verb  lists. 

Similarly,  a list  of  official  nomenclature  could  be  developed  (during  the 
TM  writing  phase)  for  each  procurement.  This  list  would  serve  as  the  official  source 
of  nomenclature  for  hardware  items.  Once  again,  such  a list  would  serve  to  insure 
consistency  in  the  writing  and  minimize  the  confusion  that  can  result  from  referring 
to  the  same  equipment  item  by  more  than  one  name.  Also,  guidelines  should  be 
developed  that  direct  the  use  of  coloquial  nomenclature.  Such  nomenclature  is  com- 
monly used  within  a maintenance  instruction  to  identify  an  item  of  hardware  by 
reference  to  its  functions  (e.g.,  adjustment  screw),  type(e.g.,  insulated  washer), 
or  location  (e.g.,  motor  brush  or  assembly  vs.  generator  brush  assembly). 

Finally,  guidelines  for  the  use  of  standard  statements  could  be  developed 
and  incorporated  into  the  writers  guide.  Standard  sentences  should  be  used  to  de- 
scribe maintenance  actions  where  task  steps  are  the  same  or  highly  similar.  Each 
repetition  of  a similar  task  step  would  thus  be  written  using  the  same  sentence, 
with  the  exception  of  any  unique  data  (e.g.,  expected  indication,  test  point,  or 
where-to-go-next). 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.3  - Publishing  Subsystem 

4.3.1  DESCRIPTION  OF  PUBLISHING  SUBSYSTEM 


The  preliminary  concept  for  publishing  provides  decentralized  internal  Navy  capabil- 
ities to  accept  the  equipment  contractor's  digital  output  for  processing  through  produc- 
tion, mastering,  replication,  and  final  delivery.  A feature  of  this  concept  is  automated 
facilities  to  process  new  and  updated  text  and  graphics. 


The  Publishing  Subsystem  accepts  the  technical  information  output  of  the 
content  generator,  processes  it  into  TMs,  and  delivers  it  to  the  user.  This  is  accom- 
plished by  four  functions:  digital  production,  mastering,  replication,  and  TM  supply. 

The  digital  production  function  (Figure  4-13)  contains  the  entry,  proces- 
sing, and  storage  subfunctions.  The  entry  subfunction  provides  the  capability  to 
receive  technical  information  generated  both  by  equipment  contractors  and  internal 
Navy  content  generation  activities,  and  to  edit,  update,  and  process  the  technical 
information  for  mastering  of  TMs. 

The  mastering  function  converts  the  processed  output  to  masters  (making 
the  master  for  replication  such  as:  repro  copy,  negative,  or  video  disc  original  re- 
cording). This  function  must  be  able  to  accommodate  various  media  as  medium/ 
media  selections  are  made.  The  replication  function,  also  medium  dependent,  con- 
tains the  subfunctions  needed  to  replicate  the  medium  selected. 

The  TM  supply  function  provides  the  capability  for  packaging  and  shipping 
new  and  updated  TMs  in  response  to  distribution  requirements  provided  by  the  Dis- 
tribution Subsystem. 

Preliminary  Subsystem  Concept  - The  preliminary  concept  of  Publishing 
is  to  have  an  internal  Navy  automated  text  and  graphic  processing  system  coupled 
to  automated  medium  mastering  and  replication  systems.  This  capability  will  be 
used  to  enter  and  edit  technical  information  from  equipment  contractors  as  well 
as  that  generated  within  the  Navy.  It  will  also  be  used  to  update  TMs. 

The  technical  information  output  of  equipment  contractors  for  new  TMs 
will  be  entered  into  the  Navy  Publishing  Subsystem,  not  as  repro  copy  or  negatives, 
but  as  digital  tape  structured  as  TMs.  This  data  will  be  processed  by  the  Navy  into 
the  medium  selected  for  delivery  to  the  user.  It  will  also  be  entered  into  the  Navy 
TM  data  base  for  subsequent  updating. 

Since  the  Publishing  Subsystem  is  structured  to  fully  process  text  and  graph- 
ics from  Navy  content  generators,  the  technical  information  on  the  digital  tape  from 
equipment  contractors  can  also  be  edited  and  updated  by  the  Navy.  Although  the 
concept  of  having  a current  Navy  TM  data  base  is  primarily  to  provide  an  effective 
means  to  perform  TM  updating  when  equipment  transitions  from  in-production  to 
out-of -production  status,  the  data  base  will  allow  the  Navy  to  also  perform  updates 
on  in-production  equipment  TMs  when  expedient  or  economical. 

Decentralization  - The  Publishing  Subsystem  would  be  decentralized  among 
the  major  acquisition  activities.  The  functions  established  for  each  major  acquisi- 
tion activity  could  be  organizationally  either  part  of  that  activity  or  part  of  the 
NTIP  System  but  dedicated  to  the  major  acquisition  activity.  There  is  obviously 
a need  to  distribute  functions  on  the  basis  of  the  amount  of  work  to  be  processed 
annually  (3  to  4 million  pages)  plus  the  size  of  the  TM  inventory  (25  million  TM 
pages).  These  divisions  can  be  made  by  specific  commodity  to  be  supported,  assigned 
missions,  geographical  locations,  or  similar  factors. 

The  key  factors  in  the  decentralization  are  to  provide  the  same  capability 
at  each  location  and  to  insure  that  they  function  with  the  same  specifications  and 
standards.  In  particular,  the  standards  for  automated  interfaces  must  be  consistent 
so  any  Navy  Publishing  activity  can  accept  output  from  any  equipment  contractor 
and  from  each  other. 
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Technology  - Technology  and  industry  development  trends  show  that  in  the 
1980-85  time  frame,  digital  processing  of  text  and  graphics  may  reach  full  imple- 
mentation throughout  the  publishing  field.  Those  who  support  Navy  TM  require- 
ments, including  the  very  small  Navy  contractor,  will  either  possess,  or  have  access 
to,  automated  digital  publishing  capability.  Therefore,  any  requirement  for  con- 
tractors to  deliver  machine  readable  (digital  tape)  technical  information  to  the  Navy 
can  be  met. 

The  Navy  has  progressed  significantly  in  the  area  of  automation  as  evidenced 
by  ADFKEPS  and  TRUMP.  One  approach  to  the  Publishing  Subsystem  is  to  accommo- 
date both  of  these  systems  by  bringing  them  to  a level  of  performance  that  meets  tlie 
.lavy/Contractor  interface  requirements  and  can  handle  the  type  and  volume  of  work 
expected  by  NTIPS.  An  alternative  would  be  to  develop  totally  new  systems.  Since 
some  additional  capability  is  needed  to  meet  the  expanded  internal  workload,  new 
systems  using  the  latest  technology  are  a consideration. 

In  addition  to  the  above  text  and  graphic  processing,  technology  factors 
in  all  areas  impacting  the  Publishing  Subsystem,  such  as  video  disc  and  hologram 
development,  advances  in  high  capacity  inexpensive  computer  memories,  and  work 
in  data  compaction  and  digital  communications  were  considered  in  developing  the 
preliminary  concept.  The  research  reported  in  the  NTIPP  Task  1 Report  contains 
discussions  of  the  availability  and  applicability  of  these  technologies  and  how  they 
relate  to  mastering  and  replication  as  well  as  digital  production. 


Figure  4-13.  Publishing  Subsystem.  The  functions  shown  provide  tlic  capability  for  digital  processing 
of  text  and  graphics. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.3  - Publishing  Subsystem 


4.3.1  DESCRIPTION  OF  PUBLISHING  SUBSYSTEM  (Continued) 


Media  - The  NTIPS  preliminary  concept  considers  the  currently  used  printed 
paper  books  and  microforms  (roll  and  fiche)  as  the  primary  media  that  Publishing 
must  accommodate.  Since  other  media  (video  discs,  digital  holograms,  and  digital 
data  delivered  directly  to  the  user)  must  also  be  accommodated,  the  Publishing  func- 
tions most  affected  by  media  must  be  set  up  as  multimedia  functions.  Table  4-10 
shows  that  mastering,  replication  and  TM  supply  must  perform  their  functions  with 
a different  methodology  for  each  medium.  Furthermore,  mastering  and  replication 
also  generally  need  different  devices  for  each  methodology. 

Use  of  Publishing  Services  Contractors  - The  use  of  outside  contractors 
for  Publishing  services  is  a considered  alternative.  One  possibility  would  be  the 
total  performance  of  all  Publishing  functions  by  contractors.  Currently,  one  func- 
tion (TM  printing)  is  totally  contracted,  and  several  others  are  partly  done  outside 
the  Navy.  Thus,  total  contracting  for  Publishing  is  basically  feasible. 

A key  factor  to  be  considered  regarding  contracting  is  the  Office  of  Man- 
agement and  Budget  circular  A76  and,  in  addition  for  replication,  the  policy  of  the 
Joint  Committee  on  Printing  (JCP).  OMB-A76  and  the  JCP  policy  both  require  that 
contractors  should  be  considered  for  services  such  as  performed  by  publishing  func- 
tions. This  one  factor  makes  contracting  of  the  Publishing  Subsystem,  or  at  least 
major  parts  of  it,  a very  viable  alternative. 

Structuring  the  Engineering  Data  Base  for  Direct  TM  Production  - Another 
subsystem  alternative  to  be  considered  is  the  automation  of  the  engineering  data 
base  to  the  extent  that  it  could  output  TMs.  The  requirements  for  TM  content  gener- 
ation would  be  applied  to  the  development  of  engineering  data  to  enable  direct  gen- 
eration of  usable  TMs,  thus  eliminating  the  need  for  rewriting  or  redrawing.  The 
content  generator  would  perform  any  reprocessing  and  supplement  the  data  as  needed. 
The  data  would  be  created  in  digital  form  ready  for  mastering  in  the  selected  media, 
for  entering  into  the  NTIPS  data  bank,  or  for  delivery  directly  to  the  user. 

This  concept  would  essentially  eliminate  a formal  digital  production  function 
in  Publishing  except  for  updating  out-of-production  equipment  TMs.  There  is  no 
equipment  contractor  engineering  effort  after  equipment  transitions  to  the  out-of- 
production status.  If  the  Navy  does  not  pick  up  the  equipment  contractor's  data 
base  and  use  the  contractor's  method  of  operation,  then  conventional  content  gen- 
eration and  publishing  processes  would  be  needed  to  update  out-of-production  equip- 
ment TMs. 
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TABLE  4-10.  METHODOLOGY  NEEDED  FOR  CANDIDATE 
MEDIA  IN  PUBLISHING  FUNCTIONS 


Mastering 

Replication 

TM  Supply 

Printed  Paper  Books 

Photocomposition/COM 
with  Platemaking 

Printing  and 
Binding 

Packaging  and 
Delivery 

Microforms 

COM/ Micro-Photo 

Photo/Diazo/ 

Vesicular 

Packaging  and 
Delivery 

Video  Disc  (Video) 

Video/Computer  Output 
to  Video 

Photo/Diazo/ 
Disc  Pressing 

Packaging  and 
Delivery 

Video  Disc  (Digital) 

Computer  Output  to 
Video  Disc 

Photo/Diazo/ 
Disc  Pressing 

Packaging  and 
Delivery 

Digital  Holograms 

Computer  Output  to 
Hologram 

Photo/Diazo/ 

Vesciular 

Packaging  and 
Delivery 

Direct  Digital 

None 

None 

Data 

Communications 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.3  - Publishing  Subsystem 

4.3.2  DESCRIPTION  OF  DIGITAL  PRODUCTION  FUNCTION 


Digital  production  is  text  and  art  production  and  uses  a (magnetic)  digital  tape  for  input 
of  the  contractor's  TM  information.  Paper  input  from  Navy  content  generators  is  con- 
verted for  automatic  processing  by  optical  character  recognition  equipment. 

Digital  production  is  an  internal  Navy  function  that  must  accommodate 
TM  technical  information  output  from  both  contractors  and  internal  Navy  content 
generators.  The  function  must  also  input,  edit,  and  update  to  a prescribed  format, 
and  then  must  output  for  mastering  and  replication  in  a selected  medium.  Digital 
production  consists  of  the  entry,  processing,  and  storage  subfunctions. 

Entry  Subfunction  - Accepting  the  contractor's  output  is  a key  feature  of 
this  subfunction.  Since  there  are  potentially  hundreds  of  contractors  who  can  be 
creating  technical  information,  the  relationship  between  the  Navy  and  the  contrac- 
tor's operations  needs  controls  to  limit  the  number  of  different  contractor  output 
products.  For  the  purpose  of  the  preliminary  subsystem  concept,  one  product,  digital 
tape  in  ASCII  format  with  a predetermined  format  coding,  has  been  selected.  Fig- 
ure 4-14  shows  the  contractor's  output  being  fed  only  to  a tape  input  component 
of  the  entry  subfunction. 

The  requirement  for  the  digital  tape  output  assumes  that  contractors  will 
have  a publications  automation  capability  or  access  to  it  in  the  1980-85  time-frame. 
The  automated  publications  systems  employed  will  probably  be  functionally  compar- 
able to  that  presented  in  this  report  for  the  internal  Navy  operations.  Therefore, 
formatted  digital  tape  will  be  a feasible  output.  Alternatives  such  as  optical  char- 
acter recognition  (OCR)  and  graphic  scanning  should  be  considered  and  are  discussed 
in  the  following  topic. 

The  second  feature  of  the  entry  subfunction  is  the  fully  automated  capabil- 
ity to  input,  edit,  and  update  technical  information  being  received  from  Navy  con- 
tent generators  using  internal  (Navy)  components.  These  components  are  needed 
to  accommodate  both  text  and  graphics  and  include  both  batch  and  interactive 
processing.  They  are; 

• Batch  Text  Input  - This  component  accepts  text  material  prepared  on 
"standard"  typewriters  and  reads  it  into  the  processing  subfunction  with 

a special  OCR  device.  This  is  discussed  in  the  Task  1 Report,  page  3-216. 
Although  presented  here  as  an  internal  Navy  entry  component,  it  is  also 
an  alternative  for  entry  of  contractor  text  output. 

• Interactive  Text  Edit  and  Update  - This  component  provides  the  capa- 
bility  for  an  operator  to  make  copy  changes  using  devices  that  utilize 
the  processor's  editing  software.  For  example,  such  actions  as  copy 
deletions,  additions,  or  relocations  can  be  performed  very  efficiently 
using  a device  such  as  a video  display  terminal.  Although  an  interactive 
device  can  be  used  for  text  input,  it  will  not  be  used  where  batch  input 
capability  is  available. 

• Interactive  Graphic  Input,  Edit,  and  Update  - This  component  provides 
the  capability  to  handle  graphics  in  intelligent  form  and  enables  entry, 
manipulation,  and  changing  of  lines,  symbols,  and  alphanumerics.  (See 
Task  1 Report,  page  3-218.) 

This  subfunction  must  be  able  to  handle  the  total  yearly  volume  of  technical 
information  from  all  content  generators.  With  over  3 million  pages  of  new  TMs  en- 
tering the  system  each  year,  an  additional  one-half  million  pages  of  updates,  and 
several  hundred  thousand  pages  of  other  changes  backlogged,  the  entry  subfunction 
and  the  associated  processing  and  storage  subfunctions  may  have  to  be  distributed. 
I'he  capability  would  be  decentralized  within  the  major  organization  activities  and 
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further  distributed  based  on  processing  hardware  capacity,  geographical,  or  com- 
modity considerations. 

Processing  Subfunction  - This  subfunction  provides  the  computer  power, 
including  an  adequate  set  of  software,  to  accommodate  the  number  of  input-output 
functions  (and  devices)  needed  to  support  the  workload.  It  consists  of  digital  editing 
and  digital  formatting  components. 

The  digital  editing  component  controls  and  accommodates  the  text  and 
graphic  input,  edit,  and  update  modes.  Digital  editing  includes  the  software  needed 
to  process  the  TI  being  entered  and  to  reprocess  it  through  edit  or  update  cycles. 
Digital  formatting  provides  format  and  output  controls  to  produce  the  end  product 
(in  digital  form)  that  is  prescribed  for  conversion  to  the  selected  media  for  subse- 
quent distribution  to  the  user.  Software  provides  for  meeting  the  mechanical  speci- 
fications that  derive  from  the  media  selected  for  mastering  and  replication.  Such 
format  factors  as  type  size,  column  width,  line  weight,  and  graphic  symbology  are 
controlled  here. 

The  editing  and  formatting  components  will  be  colocated  with  the  entry 
subfunction.  Consideration  will  be  given  to  netting  the  distributed  processing  sub- 
functions to  provide  for  cross  use  of  central  data  banks  or  for  specialized  processing 
needs. 

Many  computer  programs  will  be  necessary  to  provide  the  processing  power 
for  complete  automation  of  text  and  graphics.  The  essential  ones  are: 

• Input  and  edit  - add,  delete,  move,  scroll,  change  column  width,  line 
spacing,  etc. 

• Data  manipulation  extracting  and  storage  - unit  address,  absolute  ref- 
erence system,  variable  relocation. 

• Global  operations  - locate  and  replace. 

• Nondistorted  tabular  editing. 

• Text  and  graphic  merge. 

• Full  character  set  - range  of  type  faces  and  sizes,  special  characters, 
Greek  letters,  math  symbols. 

• Full  range  of  graphic  symbols. 

• Horizontal  and  vertical  rule. 

• Hyphenation  and  justification. 

• Output  formatting  (text)  - pagination,  extraction  of  front  matter,  mar- 
ginal copy. 

• Output  formatting  (graphics)  - sizing  and  placement. 

• Output  simulation  - high  speed  devices  (for  proofing  batch  text  and 
graphics). 

Storage  Subfunction  - This  subfunction  provides  the  working  storage  for 
technical  information  being  processed  in  content  capture.  It  has  two  components, 
on-line  and  off-line  storage.  The  direct  interface  between  the  TM  data  base  (archive 
function  of  the  Distribution  Subsystem)  and  the  storage  subfunction  is  through 
the  off-line  working  storage  component.  This,  in  turn,  is  interfaced  to  the  on-line 
working  storage  component,  needed  by  the  processing  subfunction.  The  off-line 
working  storage  will  contain  the  technical  information  to  be  processed  in  pub- 
lishing - say  20  or  25  TMs  being  updated.  The  on-line  working  storage  will  contain 
only  the  data  being  worked  on  at  that  particular  time  by  the  operators.  After  an 
operator  is  finished  with  a file  of  data,  it  will  be  placed  in  off-line  working  storage 
if  further  work  is  to  be  done  at  a later  time,  or  sent  back  to  the  TM  data  base  (ar- 
chive) if  no  further  work  is  needed.  The  complete  TM  is  also  sent  to  the  mastering 
subfunction  for  conversion  to  the  selected  media  masters. 


Working  storage  for  the  preliminary  system  concept  is  high-density  magnetic 
tape  for  off-line  storage  and  hard  disc  for  the  on-line  storage.  These  are  both  cur- 
rently good  cost/performance  storage  media  that  with  expected  constant  improve- 
ment will  continue  to  be  inexpensive  and  reliable  storage  methods  for  at  least  the 
next  three  to  five  years. 

Two  existing  and  evolving  Navy  systems,  Automated  Document  Preparation 
Systems  (ADPREPS)  and  Technical  Review  and  Update  of  Manuals  and  Publications 
(TRUMP),  both  contain  some  of  the  basic  components  of  entry  and  processing.  Both 
are  capable  of  growth  to  accommodate  the  added  components  required  for  NTIPS. 
However,  these  two  systems  can  handle  only  a part  of  the  Navy's  total  TM  update 
needs  (up  to  800K  pages  per  year).  Conversely,  the  amount  of  new  TMs  generated 
internally  by  the  Navy  each  year  (less  than  50K  pages)  could  probably  be  handled 
by  either  system  with  both  text  and  graphic  capability.  Both  the  ADPREPS  and 
TRUMP  systems  were  considered  in  developing  the  NTIPS  preliminary  system  con- 
cept and  will  figure  in  the  design  of  the  Publishing  Subsystem. 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.3  - Publishing  Subsystem 


4.3.3  DIGITAL  PRODUCTION  FUNCTION  ALTERNATIVES 


The  principal  alternatives  to  the  concept  of  automated  digital  production  are  the  man- 
ual input,  edit,  and  update  methods,  and  the  use  of  publishing  contractors  to  perform 
selected  production  operations.  The  distribution  of  the  processing  subfunction  among 
the  cognizant  field  activities  is  an  organizational  alternative.  

Viable  alternatives  for  production  operations  are  shown  in  Table  4-11.  The 
first  alternative  is  the  use  of  manual  methods  of  entry  and  processing.  An  exam- 
ple of  this  would  be  substituting  manual  graphic  preparation  for  automated  graphic 
preparation.  In  this  case,  the  input  mode  would  change  from  the  interactive 
terminal/plotter  to  a digital  scanner,  and  the  processor  (computer)  would  not  need 
graphic  character  sets,  plotting  routines,  and  other  graphic  software.  However, 
going  from  a vector  graphic  presentation  (of  automated  graphics)  to  the  raster  scan 
graphic  (of  image  only)  would  actually  result  in  an  increased  need  for  both  computer 
core  and  working  storage.  There  is  also  some  chain  reaction  to  be  considered  be- 
cause this  approach  would  have  some  impact  on  the  archive  function  and  on  the 
mastering  function  as  it  applies  to  some  potential  digital  media  typ^  •. 

There  are  also  combinations  of  manual  and  automated  subfunctions  that 
can  be  applied,  such  as  automated  text  processing  and  manually  prepared  graphics. 
This  is  viable  because  automated  graphics  has  not  yet  reached  the  advanced  state 
of  automated  text.  As  alternatives,  the  manual  methods  need  to  be  scrutinized 
in  areas  of  cost,  quality,  and  throughput.  The  major  impact  of  manual  methods 
would  be  to  the  archive,  which,  because  it  is  digitally  centered,  would  require  further 
conversion  before  entry  into  storage. 

Using  Contractors  to  Perform  Publishing  Operations  - The  next  major  alter- 
native isTfieuse''or'contractors~fo''perro?rfrseIecteTpuEn?lTrng  subfunctions.  For 
example,  all  entry  and  processing  could  be  done  by  contractor,  or  only  text  and 
graphic  input  could  be  contracted.  This  alternative  addresses  the  AIA's  concernl 
over  the  Navy's  alleged  departure  from  the  Office  of  Management  and  Budget  policy 
as  stated  in  circular  OMB-A76.  This  policy  provides  the  guidelines  for  use  of  con- 
tractors for  such  services  as  publishing  operations.  Again,  the  principal  area  af- 
fected would  be  the  archive  because  coordination  and  control  of  access  to  the  data 
base  would  be  more  difficult  if  another  level  of  operation  (the  contractor)  were 
added.  Using  contractors  for  some  subfunctions,  such  as  text  keyboarding  for  the 
batch  input,  would  have  minimal  impact. 

Entry  and  Processing  - Within  these  subfunctions  there  are  other  viable 
alternative  approaches: 

• Contractor  output  of  typewritten  text  pages  and  copies  of  graphics  can 
be  used  in  place  of  digital  tape  (as  an  input  to  the  entry/processing  sub- 
functions). To  maintain  the  digital  TM  data  base,  both  text  and  graphics 
would  be  scanned  into  the  processor  and  stored  digitally.  There  is  a 
second  alternative  of  text  on  tape  with  photo  copies  of  graphics.  Here, 
the  text  tape  is  read  into  the  processor  and  the  graphics  digitally  scanned 
into  the  processor.  These  alternatives  impact  the  processor  and  working 
storage. 

• Voice  recognition  is  an  alternative  to  keyboard/optical  character  recog- 
nition (OCR)  for  batch  text  input.  This  technique,  discussed  in  the  Task  1 
report,  page  3-216,  is  a developing  technology  that  has  a potential  impact 


1.  Aerospace  Industries  Association.  PUBS-100  Panel;  Navy  TRUMP  System  Acti- 
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TABLE  4-11.  COMPARISON  OF  PRELIMINARY  CONCEPT  AND 
ALTERNATIVES  FOR  DIGITAL  PRODUCTION 


Basic 

Operations 

Preliminary 

Concept 

(Automated) 

Alternative 

(Manual) 

Alternative 

(Contract) 

Other 

Alternatives 

Accepting  input 
from  contractor 

Magfnetic  digital 
tape 

Typewritten  text 
pages  and  copies 
of  graphics 

Contractor  obtains 
automated  output 
(magnetic  tape) 
by  subcontract 

Mix  of  automated 
and  manual 

Mix  of  contract 
and  internal 

Input  generated 
by  internal  con- 
tent generation 
function 

Typewritten  text 
pages  optically 
scanned  and 
graphics  created 
interactively  by 
computer 
assistemce 

Typewritten  text 
pages  and  man- 
ually prepared 
graphics 

Either  the  manual 
or  automated  mode 
can  be  obtained  by 
contract 

Voice  recognition 
text  input 

Symbolless  graph- 
ics using  alfrfia- 
numeric 
representation 

Mix  of  automated 
and  manual 

Mix  of  contract 
and  internal 

Internal  edit 
and  update 

Make  changes  in- 
teractively to 
text  and  graphics 

Correct  the  type- 
written text  and 
manually  prepared 
graphics  using 
same  methods  as 
used  for  originals 

Same  as  above 

Mix  of  automated 
and  manual 

Mix  of  contract 
and  internal 
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4.3.3  DIGITAL  PRODUCTION  FUNCTION  ALTERNATIVES  (Continued) 


on  cost  since  the  author's  output  (his  dictated  text)  would  be  entered 
directly  into  working  storage  through  the  processor.  Most  applications 
could  use  a combination  of  voice  input  for  text  plus  keyboard  input  for 
tabular  material. 

• In  place  of  diagrams  using  conventional  graphic  symbols,  a "symbolless 
graphics"  presentation  can  be  employed.  This  can  be  done  using  a slightly 
modified  alphanumeric  keyboard.  Block  diagrams,  schematics,  wiring 
layouts,  flow  diagrams,  and  other  similar  line  drawings  (but  not  many 
types  of  mechanical  drawings)  can  be  prepared  without  symbols.  An 
example  (a  digital  logic  mechanization  diagram)  is  shown  in  the  Task  1 
report,  page  3-221.  This  alternative  would  significantly  reduce  digital 
storage  requirements  since  a graphic  prepared  in  this  manner  would  have 
about  the  same  number  of  digital  bits  to  store  as  a full  page  of  text. 

The  conventional  drawing  in  digital  form  has  many  times  more  digital 
bits  than  the  text  page. 

Alternatives  at  the  Component  Level  - Within  the  components  of  the  sub- 
f unctions  there  are  varying  degrees  of  alternative  approaches.  Most  relate  to  the 
manual  vs.  automated  and  the  internal  vs.  contract  factors  discussed  above.  How- 
ever, there  are  two  unique  subfunction  alternatives: 

• Using  interactive  input  for  text  as  well  as  edit  and  update  as  an  alter- 
native to  the  combined  batch  input  and  interactive  edit  and  update. 

This  could  be  cost  effective  in  small  operations  that  cannot  support 
separate  batch  input. 

• Using  batch  input  of  graphics,  providing  it  can  be  read  into  the  computer 
in  intelligent  forms  (as  separate  symbols,  lines,  and  callouts)  as  an  alter- 
native to  the  interactive  graphic  input.  Some  drawings  would  be  pre- 
pared manually  and  then  digitally  scanned.  There  could  be  a cost  impact 
on  operations  with  large  volumes. 

Netted  Processing  of  Data  - At  the  component  level,  but  relating  directly 
to  the  processing  subfunction,  there  is  another  significant  alternative  to  be  con- 
sidered. It  is  the  netting  of  the  processors  (computers)  at  the  various  locations  per- 
forming publishing  work  as  an  alternative  to  the  processors  functioning  indepen- 
dently. The  netted  publishing  operations  could  then  be  structured  to  handle  special- 
ized TMs  at  designated  locations.  One  processor  could  process  only  new  Illustrated 
parts  manuals,  another  workcards,  and  a third  updates  of  out-of-production  equip- 
ment manuals.  Another  mode  of  distribution  would  be  to  have  all  capabilities  at 
each  location  and  distribute  the  volume  of  work  as  needed.  Distributing  the  proc- 
essing may  cut  across  missions,  commodities,  or  geographical  boundaries  and  there- 
fore be  effective  only  on  a limited  basis.  This  alternative  approach  offers  potential 
cost  advantages  and  impacts  both  the  Content  Generation  Subsystem  and  NTIPS 
Management  Subsystem. 

Storage  Alternatives  - Alternatives  of  the  storage  subfunction  (Table  4-12) 
directly  relate  to  the  alternative  approaches  of  the  other  subsystem  functions. 

In  the  case  of  a manually  implemented  publishing  subsystem,  working  storage  for 
"on-line"  storage  would  be  visual  media,  such  as  the  repro  text  copy  and  original 
artwork,  while  microform  or  even  video  disc  could  be  used  for  "off-line"  storage. 

The  "off-line"  storage  would  probably  be  in  the  same  medium  as  used  for  storage 
in  the  archive.  More  likely,  the  processing  and  storage  subfunctions  will  remain 
digital.  Therefore,  the  alternatives  become  the  newly  developing  media  - bubble 
and  CCD  memories,  for  example.  These  could  become  candidates  should  their  capa- 
bilities be  broadened  and  their  cost  reduced.  Physical  size  is  not  as  much  of  a 
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concern  in  the  working  storage  applications  as  in  the  archive  function  since  working 
storage  requires  less  capacity. 

A continuing  assessment  of  technology  is  needed  in  the  field  of  storage  media 
because  the  state  of  the  art  is  continually  changing.  Along  with  delivery  and  user 
(presentation)  media  and  text  and  graphics  automation,  there  are  sufficient  promising 
developments  and  new  approaches  to  warrant  further  investigations  and  evaluations 
throughout  the  design  process  of  an  NTIP  System  and  beyond.  This  would  fall  within 
the  charter  of  the  R&D  subf unction  in  the  NTIPS  Management  Subsystem. 


TABLE  4-12.  COMPARATIVE  SUMMARY  OF  STORAGE  ALTERNATIVES 


Basic 

Operations 

Preliminary 

Concept 

(Automated) 

Alternative 

(Automated) 

Alternative 

(Manual) 

On-line  working 
storage 

Hard  discs 

Non-Identified 

Repro  copy  (text) 
Original  artwork 

Off-line  working 
storage 

Magnetic  tape 

Video  disc  (digital) 
Digital  hologram 
Bubble  memory 
Charged  coupled 
device  memory 

Video  disc  (visual) 
Microform 
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4.3.4  DESCRIPTION  OF  MASTERING,  REPLICATION,  AND  TM  SUPPLY  FUNCTIONS 


The  mastering,  replication,  and  TM  supply  functions  accommodate  either  paper  or 
microform  as  the  media  for  the  TM  delivered  to  the  user.  Each  function  therefore 
is  designed  to  operate  in  two  different  modes. 

The  activities  of  the  mastering,  replication  and  TM  supply  functions  (see 
Figure  4-15)  are  primarily  media-oriented.  The  mastering  function  receives  the 
TM  in  a digital  form  from  the  processing  function  and  produces  a master  in  the 
medium  selected  for  replication.  Replication  produces  copies  of  the  master  in  the 
medium  selected  for  delivery  to  the  user.  TM  supply  provides  packaging  and  ar- 
ranges shipment  to  the  TM  users,  in  the  proper  quantities,  as  designated  in  the  ship- 
ping directive  provided  by  the  Distribution  Subsystem. 

For  the  NTIPS  preliminary  system  concept,  all  the  media  currently  employ- 
ed to  place  the  TM  in  the  user's  hands  are  considered  feasible: 

• Microforms  - Presently  two  microforms  are  in  use  for  TMs:  microfiche 
and  roll  microfilm  packaged  in  cartridges.  Both  require  a viewer.  See 
Task  1 report,  page  3-240. 

• Paper  (Printed)  Books  - Presently  the  most  used  medium.  As  a replica- 
tion medium  for  delivery  to  multiple  users,  printing  is  considered  as 
interim.  In  the  preliminary  system  concept  it  becomes  a secondary 
medium.  See  Task  1 report,  page  3.230. 

Other  user  media  considered  viable  for  potential  use  in  the  post-1980s  time  frame 


are: 

• Video  Discs  - New  technology  that  provides  either  visual  images  or 
digital  representations  of  TM  text  and  graphics  on  a 12-inch  disc.  Can 
also  provide  video  presentations  of  actions.  Requires  converter  and 
viewer.  See  DTNSRDC  video  disc  technology  assessment  ^ for  full 
discussion. 

• Hologram  - New  technology  providing  either  a digital  representation 
or  a combined  digital  and  visual  (microform)  presentation  on  a 
microfiche-size  film.  Needs  converter  and  viewer.  See  Task  1 report, 
page  3-254. 

• Direct  Digital  - Delivery  of  the  TM  in  digital  form  via  direct  transmis- 
sion to  the  user  using  telephone/telegraph  lines  or  radio/microwave 
links.  Requires  storage,  converter,  and  viewer  at  user's  locale. 

With  the  exception  of  paper  books,  utilization  of  most  of  the  above  media 
requires  that  TM  users  be  provided  with  a means  of  producing  paper  copies.  For 
example,  in  most  microform  applications  the  user  has  access  to  a viewer/printer. 
The  subject  of  the  viewer/printer  in  the  user  community  and  some  of  the  problems 
encountered  are  discussed  in  Topic  3.8. 

Mastering  - The  mastering  function  converts  the  digital  stream  of  data 
from  the  processing  subfunction  into  a physical  entity.  Mastering  is  such  an  inte- 
gral part  of  the  entire  publishing  process  that  it  should  be  colocated  with  the  entry 
and  processing  subfunctions.  For  any  medium/media  used  in  NTIPS,  sufficient 
capability  must  exist  to  output  masters  for  the  nearly  4 million  new  or  updated 
TM  pages  each  year.  As  with  entry  and  processing,  mastering  must  accommodate 
both  text  and  graphics.  This  requires  output  devices  that  can  provide  masters  with 
the  text  and  graphics  merged.  For  media  such  as  printed  books  and  microforms. 
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NTIPS  MANAGEMENT  SUBSYSTEM 

• MANAGEMENT  INFORMATION  SYSTEM  (MIS) 

• policies  AND  PROCEDURES 

• CONVERSION  AND  REPLICATION  STANDARDS 


INITIAL  DISTRIBUTION 
CONTROL  FUNCTION 


Figure  4-15.  Mastering,  Replication,  and  TM  Supply  Functions.  The  relationship  to  the  Navy 
Publications  and  Printing  Services  Office  (NPPSO)  is  shown. 
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the  devices  are  piiotocomposition  and  computer  output  microform  (COM),  For 
digital  video  disc,  digital  hologram,  or  direct  digital,  there  is  no  problem  of  text/ 
graphics  merge,  but  there  is  the  problem  of  the  significantly  greater  storage  re- 
quirement when  graphics  are  furnished  in  digital  form  along  with  text.  For  image 
video  disc  applications,  there  is  no  problem  of  merge  or  storage. 

Mastering  is  comprised  of  two  subfunctions,  conversion  and  mastering. 

I'he  first,  conversion,  takes  the  digital  representation  from  the  processing  subfunc- 
tion and  converts  it  to  provide  the  data  structure  and  instructions  needed  for  the 
mastering  device.  The  mastering  subfunction  is  the  physical  preparation  of  the 
media  master. 

Replication  - The  master  for  any  media  must  be  reproduced  into  the  num- 
ber of  copies  specified  by  the  shipping  directives  in  support  of  the  system/ 
equipment  for  which  the  information  was  generated.  The  particular  medium  will 
determine  the  specific  methods  to  be  employed.  Basic  replication  methods  and 
variations  are  discussed  in  the  Task  1 report  topics  covering  the  Replication  Re- 
search Issue.  At  present,  paper  book  printing  and  microform  duplication  are  essen- 
tially totally  contracted  functions.  No  change  in  this  structure  is  anticipated.  All 
replication  activity  for  other  media  is  considered  an  internal  Navy  function.  It  would 
be  an  integral  element  of  the  NTIPS  publications  functions  distributed  among  various 
field  activities. 

The  Distribution  Subsystem  archive  function  in  coordination  with  N TIPS 
Management  Subsystem  activities  processes  TM  replenishment  requests  (and  ap- 
propriate TM  masters)  to  the  replication  function.  In  this  way,  new  supplies  of  out- 
of-stock  TMs  are  provided  to  the  resupply  function. 

A key  factor  in  operation  of  the  replication  function  is  the  Navy  Publications 
and  Printing  Services  Office  (NPPSO).  NPPSO  is  the  replication  arm  of  the  Navy 
and  is  cognizant  over  existing  media  replication  (paper  and  microforms).  Should 
these  media  be  replaced  by  video  disc  or  hologram,  it  is  anticipated  their  replication 
would  be  subject  to  the  same  control.  Through  NPPSO  the  policies  of  the  Con- 
gressional Joint  Committee  on  Printing  (JCP)  and  the  Government  Printing  Office 
(GPO)  are  also  imposed, 

TM  Supply  - The  TM  supply  function  distributes  the  output  of  the  replica- 
tion function.  It  packages  TMs,  affixes  shipping  labels,  and  arranges  transporta- 
tion. Instructions  for  distribution  are  issued  by  the  Distribution  Subsystem's  initial 
distribution  control  function  in  the  form  of  shipping  directives.  Based  on  this  in- 
formation, the  required  quantities  of  TMs  are  assembled  for  each  addressee  and 
shipping  labels  attached.  Transportation  will  be  based  on  the  priority  of  need  and 
bulk  of  material  to  be  shipped.  Here  again,  media  selection  has  a significant  im- 
pact on  the  type  of  packaging  to  be  used  and  the  amount  of  environmental  protec- 
tion required. 

It  might  seem  that  TM  supply  should  reside  in  the  Distribution  Subsystem, 
but  the  most  efficient  way  to  distribute  new  and  updated  TMs  (from  a time  and 
cost  standpoint)  is  from  the  source  of  replication.  As  with  the  mastering  and  repli- 
cation functions,  TM  supply  will  reside  physically  as  a working  element  of  the  repli- 
cation function  of  the  various  publications  field  activities. 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.3  - Publishing  Subsystem 

4.3.5  MASTERING,  REPLICATION.  AND  TM  SUPPLY  FUNCTION  ALTERNATIVES 


Alternative  concepts  for  the  mastering,  replication,  and  TM  supply  functions  are  con- 
cerned primarily  with  the  tradeoffs  between  manual  versus  automated  operations,  and 
contracted  versus  internal  Navy  publishing  methods. 

The  media  presented  in  the  previous  topic  must  be  accommodated  in  the 
preliminary  system  concept  although  the  final  decision  to  switch  to  some  of  them 
may  not  be  made  for  a number  of  years.  Alternatives,  both  manual 's.  automated 
and  internal  Navy  vs.  contracted  services,  are  compared  in  labl'-  ^ l.i. 

Manual  vs  Automated  Operations  - At  the  functional  level,  the  first  alter- 
native is  the  use  of  manual  in  place  of  automated  publishing  methous.  Should  the 
digital  production  functions  be  performed  without  computer  assistance,  the  muster- 
ing function  would  remain  as  presently  structured,  mostly  manual  with  some  auto- 
mated assist.  The  output  of  content  capture,  typewritten  pages  and  manually  pre- 
pared drawings,  would  be  processed  into  printing,  microform,  or  visual  image  video 
disc  masters.  Generally,  if  content  capture  is  totally  automated,  it  follows  that 
the  output  element  (mastering)  should  also  be  totally  automated. 

For  the  replication  and  TM  supply  functions,  the  manual  versus  automated 
alternative  has  little  impact.  The  printing  and  microform  duplicating  operations 
serving  TM  replication  needs  are  generally  semi-automated  to  the  point  that  is 
cost  effective.  Further  sophistication  such  as  found  in  long-run,  high-speed  news- 
paper or  periodical  printing  operations  are  not  cost  effective  for  TM  publishing. 

One  aspect  of  automation  that  would  be  effective  is  such  devices  as  automated 
electromechanical  collators  or  microform  duplicators. 

Contractor  vs  Internal  Navy  Operations  - The  contracting  alternative  has 
ramifications  that  should  be  considered.  For  mastering,  replication,  and  delivery, 
contracting  is  a most  viable  alternative  to  the  internal  Navy  capability.  Contract- 
ing of  the  mastering  and  replication  requirements  of  any  medium  (except  direct 
digital)  is  feasible.  Mastering  is  a device-oriented  function,  and  contractors  as  well 
as  Navy  organizations  could  have  the  necessary  mastering  devices.  The  output  from 
the  processing  function  (most  probably  a digital  magnetic  tape)  could  be  provided 
to  a contractor  to  process  on  his  device. 

Replication  is  also  device-oriented,  and  the  same  contractor  mode  of  oper- 
ation could  be  employed.  The  master  would  be  supplied  to  a contractor  for  repro- 
duction or  copying  on  his  replication  devices.  Likewise,  most  publishing  contractors 
would  be  capable  of  packaging,  labeling  and  shipping  directly  from  their  facility  as- 
suming they  were  provided  the  proper  instructions.  Direct  digital  is  the  exception 
since  there  is  no  "product"  to  be  mastered  or  replicated  and  "shipment"  would  re- 
quire transmission  of  the  TMs  through  use  of  hardware  not  normally  available  to 
a publishing  contractor. 

An  additional  consideration  in  the  contracting  alternative  is  various  mixes 
of  internal  and  contracted.  For  example,  mastering  could  be  done  internally,  with 
replication  and  TM  supply  accomplishment  by  contractors.  Also,  some  media  may 
be  better  suited  for  contract  because  of  high  capital  investment  for  devices  that 
would  have  low  utilization. 

One  other  consideration  in  regard  to  contracting  is  the  position  of  the 
Congressional  Joint  Committee  on  Printing  (JCP)  relative  to  the  contracting  of 
replication  media.  It  is  assumed,  for  example,  should  printed  books  and  microforms 
be  dropped  in  favor  of  video  discs,  that  replication  of  the  video  discs  would  remain 
under  JCP  cognizance.  If  so,  internal  Navy  replication  may  not  be  justified.  This 
is  because  it  is  logical  to  assume  that  there  will  be  sufficient  contractors  avail- 
able to  handle  this  or  any  other  new  replication  medium. 


4-76 


TABLE  4-13.  MAS  FEEING,  KEFLICATION  AND  FM  SUPPLY  M.TEKN A FIVES 


Basic 

Operation 

Functional 

Concept 

Functional 

Alternative 

(Manual) 

Fun  -ti  Jiial 
Mternativc 
(Contracting) 

Mastering  (in- 
cluding conver- 
sion of  content 
.capture  output) 

Preparing 
master  from 
digital  form  of 

TM  structured 
for  the  medi- 
um selected 

None  - the  output  of 
manual  entry  and 
processing  would  be 
the  medium  for 
mastering  - using 
conventional  meth- 
ods and  current 
technology 

High  Potential  - 
device  entered 

Replication 

Reproducing  or 
copying  the 
masters 

Not  considered  an 
alternative 

Very  viable  (JCP 
impact) 

TM  Supply 

Packaging, 
labeling  and 
physical 
distribution 

Not  considered  an 
alternative 

’.Vould  be  con- 
tracted along 
with  replication 
function 

Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.4  - Distribution  Subsystem 


4.4.1  Dl-SCHIPTION  OF  DISTRIBU  I’lON  SUBSYSTEM  PRELIMINARY  CONCEPT 


File  Distribution  Subsystem  provides  NTIPS  with  the  capability  to  control  deployment 
of  Navy  TMs  from  the  time  they  are  created  until  they  become  obsolete. 

Technical  manuals  must  be  made  available  to  equipment  operators  and  main- 
tainors when  and  where  needed.  Therefore  the  primary  concern  in  development 
of  a new  or  improved  approach  to  TM  distribution  is  to  satisfy  that  need.  The  systetn 
must  be  capable  of  providing  TMs  to  the  appropriate  Navy  personnel  in  the  quantities 
required  throughout  the  life  of  the  equipment.  This  requires  directing  the  distribu- 
tion of  new  TMs  or  changes  and  revisions  to  existing  deployed  TMs,  providing  a sup- 
ply resource  for  TM  users  to  obtain  replacements  for  manuals  they  require,  and 
maintaining  a complete  and  accurate  file  of  all  TM  masters  in  the  Navy's  inventory. 

The  approach  taken  in  developing  the  preliminary  concept  is  to  have  three 
functions  that  will  satisfy  all  distribution  requirements;  (1)  a decentralized  initial 
distribution  control  function  working  closely  with  the  acquisition  activities  and  using 
the  automated  Management  Information  System  (MIS)  for  configuration  and  distri- 
bution control  management,  (2)  a centralized  TM  resupply  function  to  provide  physi- 
cal storage  of  paper  and/or  microform  copies  of  TMs  in  the  Navy's  inventory,  and 
(3)  a centralized  dual  archive  function  containing  a digital  data  base  as  a working 
archive  for  use  in  update  programs,  and  a historical  archive  for  all  Navy  TMs. 

Initial  Distribution  Control  - First-time  or  initial  distribution  of  totally 
new  technical  manuals  (and  changes  and  revisions  to  existing  deployed  technical 
manuals)  is  accomplished  as  a result  of  this  function.  Its  primary  responsibility 
is  to  insure  that  shipping  directives,  usually  in  the  form  of  address  labels,  are  issued 
to  the  TM  supply  function  of  the  Publishing  Subsystem  for  physical  deployment  of 
newly  procured  technical  data.  To  do  this,  the  initial  distribution  function  must 
communicate  with  various  functions  for  collection  of  certain  pertinent  data.  This 
data  generally  falls  into  one  of  three  categories:  (1)  acquisition  status  (i.e.,  informa- 
tion pertinent  to  the  delivery  status  of  any  particular  technical  data  procurement 
action),  (2)  configuration  (i.e.,  information  pertinent  to  assignment  of  control  num- 
bers to  changes,  revisions,  and  new  manuals),  and  (3)  distribution  requirements  (i.e., 
the  actual  addresses  of  those  activities  that  are  to  be  "on  distribution"  for  the  data 
being  procured).  Most  of  this  information  will  be  obtained  from  the  acquisition  ac- 
tivities handling  the  hardware  programs  and  the  related  ILS  functions.  The  MIS 
will  be  used  as  the  primary  storage  and  retrieval  device  for  the  information.  Once 
this  data  has  been  accumulated,  the  shipping  directives  are  prepared  and  forwarded 
to  the  TM  supply  function. 

Resupply  - One-time  issuance  of  any  previously  deployed  technical  docu- 
mentation  is  the  responsibility  of  the  resupply  function.  Being  a warehousing  ac- 
tivity, it  assumes  a prime  responsibility  for  receipt,  storage,  and  retrieval  of  all 
resupply  stock.  Inventory  control,  reporting,  replenishment  forcasting,  and  printing 
of  shipping  directives  will  be  automated  through  MIS. 

A constraint  in  this  design  is  that  of  media.  Future  technologies  in  the  areas 
of  media  for  storage  or  data  usage  could  alter  storage  and  retrieval  techniques. 

For  the  preliminary  concept,  media  has  been  considered  a physically  deliverable 
product,  such  as  a video  disc,  hologram,  microform,  or  paper. 

Archive  - Storage  and  retrieval  of  the  TM  master  is  the  responsibility  of 
the  archive  function.  It  consists  of  two  subfunctions;  (1)  a historical  archive  for 
storage  of  TM  masters  for  all  TMs  deployed  by  the  Navy  regardless  of  current  con- 
figurations, and  (2)  a working  archive  in  the  form  of  a digital  data  base  that  is  ac- 
cessible by  the  major  acquisition  activities  to  be  used  to  process  TM  updates.  MIS 
will  be  used  to  control  inventory  accountability  and  to  report  archive  status  and 
activity  to  subsystem  and  system  management. 


The  need  for  the  Distribution  Subsystem  to  accumulate,  process,  and  report 
large  amounts  of  information  on  various  subjects,  such  as  materiel  management 
and  configuration  status,  requires  a high  degree  of  automation  for  the  subsystem 
to  be  effective.  This  is  conceived  to  be  via  an  extensive  MIS  designed  to  support 
all  of  ttie  NTIP  System. 
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F'igure  4-16.  Distribution  Subsystem.  The  Distribution  Subsystem  consists  of  three  functional 
elements  designed  to  be  highly  reactive,  by  utilizing  MIS,  to  TM  distribution  requirements  for 
new  procurements  and  the  supply  of  replacement  TMs  to  users. 


Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.4  - Distribution  System 

4.4.2  DESCRIPTION  OF  INITIAL  DISTRIBUTION  CONTROL  FUNCTION 


The  preliminary  concept  of  the  initial  distribution  control  function  is  that  of  a decen- 
tralized activity,  utilizing  a standardized,  automated  data  base  and  control  system 
for  control  of  distribution  requirements. 

The  task  of  the  initial  distribution  control  function  is  to  collect  the  informa- 
tion necessary  to  create  shipping  directives  for  newly  acquired  TMs  and  TM  changes 
and  revisions.  In  the  preliminary  concept,  initial  distribution  control  is  decentral- 
ized, with  one  NTIPS  control  function  dedicated  to  each  major  acquisition  activity. 

This  eliminates  the  response  problems  inherent  in  a totally  centralized  system  and 
utilizes  existing  Navy  facilities. 

A standardized  approach  to  the  collection  of  complete  and  accurate  initial 
distribution  information  must  be  created  if  new  TMs,  changes,  and  revisions  are 
to  be  delivered  in  a timely  manner.  Currently,  the  Navy  acquires  approximately 
12,000  new  TMs  and  20,000  changes  and  revisions  to  existing  TMs  per  year.  All 
these  require  initial  distribution  action.  These  figures  are  not  expected  to  change 
significantly  in  the  next  5 to  10  years  because  as  many  sysleins  leave  the  Navy's 
inventory  as  enter  it  each  year,  and  the  remainder  are  subject  to  constant  modifica- 
tions, causing  TM  changes  and  revisions. 

The  distribution  cycle  (Figure  4-17)  begins  when  notification  is  received 
from  the  TM  procurement  function  via  the  Management  Information  System  (MIS) 
that  a new  TM  number  or  revision/change  number  has  been  assigned  to  a specific 
equipment  configuration.  This  provides  notice  that  a potential  distribution  action 
is  forthcoming.  Acquisition  status,  delivery  schedule,  and  preliminary  distribution 
requirements  would  then  also  be  obtained  from  the  TM  procurement  function.  This 
information  is  input  to  a distribution  address  file  and  maintained  as  a part  of  the 
MIS.  This  file  is  structured  to  provide  a cross  reference  between  TM  (or  change/ 
revision)  number,  equipment,  user  location,  and  quantity  required  at  each  user  loca- 
tion. Finally,  TM  procurement  via  MIS  then  outputs  a TM  shipping  directive  that 
tells  the  TM  supply  function  where  and  in  what  quantity  the  preliminary  data  is 
to  be  shipped. 

Distribution  requirements  for  preliminary  TMs  differ  from  those  for  the 
final  version.  Normally,  the  preliminary  manual  will  only  be  distributed  to  those 
organizations  engaged  in  validation/verification  of  the  data.  Additional  TM  copies, 
produced  for  storage,  are  designated  as  limited  issue,  and  approval  of  the  acquisition 
program  manager  is  required  for  their  release.  An  exception  is  when  an  equipment 
is  deployed  without  the  final  version  of  the  TM  being  procured.  In  such  cases,  the 
preliminary  TM  will  be  distributed  as  if  it  were  a final  TM.  When  a final  TM  or 
change/revision  is  being  procured,  this  initial  distribution  control  process  is  repeated. 

Preliminary  distribution  requirements  for  a new  TM  would  be  revised  to  reflect 
final  requirements  and  the  distribution  address  file  updated.  Final  distribution  re- 
quirements for  changes  and  revisions  to  existing  deployed  TMs  would  be  obtained 
by  accessing  the  distribution  address  file  for  current  address  and  the  quantity  re- 
quired for  each  user  of  the  basic  TM.  This  results  in  the  "automatic"  distribution 
of  changes  and  revisions  to  all  those  users  who  are  currently  using  the  basic  manual. 

Following  the  above  action,  the  TM  master  would  be  sent  to  the  archive  function. 

The  key  feature  of  this  design  concept  is  the  creation  and  maintenance  of 
the  computerized  distribution  address/quantity  file.  With  over  140,000  TMs  in  the 
Navy's  inventory,  and  with  as  many  as  30,000  new  TMs,  changes,  and  revisions  being 
processed  per  year,  it  is  estimated  that  this  file  will  require  approximately  2.8  bil- 
lion bits  of  storage  to  hold  the  data  on  the  number  of  TMs  and  addresses  in  the  TM 
inventory. 

\ 
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Figure  4-17.  Control  of  TM  Distribution.  Having  the  ability  to  automatically  access  the  distribution 
requirements  for  changes  and  revisions  reduces  the  time  and  effort  required  to  deploy  the  data. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.4  - Distribution  Subsystem 

4.4.3  DESCRIPTION  OF  INITIAL  DISTRIBUTION  CONTROL  FUNCTION  ALTERNATIVES 


The  primary  alternative  to  the  decentralized  initial  distribution  control  function  is  to 
go  to  a centralized  organization.  The  selection  of  organizational  approach  has  a 
cijrect  impact  on  the  method  to  be  employed  for  gathering,  processing,  and  reporting 
information. 

The  preliminary  concept  for  initial  distribution  control  would  establish  ca- 
' pabilities  dedicated  to  each  major  acquisition  activity  for  standardized  information 

^ managetnent  methods  that  would  be  provided  through  the  NTIPS  management  infor- 

■ mation  system  (MIS)  computer  network.  Alternative  approaches  to  this  function  con- 
cern variations  in  its  organizational  structure  and  methods  of  implementing  an  in- 
formation management  system  (see  Figure  4-18). 

The  organizational  alternative  to  the  preliminary  concept  is  a single,  cen- 
tralized function  directed  by  and  reporting  directly  to  NTIPS  management.  Such 
an  approach  could  offer  a number  of  advantages.  It  would  concentrate  activity 
into  one  location  and  make  possible  more  precise  management  control  through  direct 
‘ access  to  cost  and  performance  information  and  observation  of  resource  utilization. 

It  would  also  eliminate  redundant  hardware  systems  required  for  collection,  storage, 
and  output  of  distribution  requirements. 

The  major  disadvantage  of  a centralized  organizational  structure  is  that 
it  limits  the  function's  ability  to  respond  quickly  by  being  farther  removed  from 

■ the  acquisition  organizations  with  which  it  must  closely  interrelate.  One  of  the 

goals  of  the  preliminary  design  process  has  been  to  assure  that  the  function  is  ca- 
pable of  responding  to  requests  for  creation  of  shipping  directives  in  accordance 

I with  the  time  constraints  imposed  by  the  materials  delivery  schedule.  Although 

^ the  high  degree  of  data  processing  automation  will  in  itself  speed  the  process,  ini- 

1 tial  distribution  activities  being  in  a different  organization  than  the  acquisition 

I activities  can  produce  communications  delays. 

^ It  is  estimated  that  there  will  be  approximately  30,000  individual  initial 

distribution  actions  per  year,  requiring  the  creation  of  an  organization  to  handle 
I the  work  load.  Additionally,  not  all  initial  distribution  actions  will  be  identical. 

1 The  different  major  acquisition  activities  have  variations  in  the  way  data  is  col- 

I lected,  stored,  and  retrieved,  or  in  the  particular  information  collected.  Such  varia- 

i tions  could  reduce  even  more  the  centralized  organization's  ability  to  be  responsive. 

Distribution  Addressee  Files  Alternative  - As  described  in  the  preliminary 
concept,  information  management  will  be  accomplished  through  creation  and  main- 
tenance of  distribution  address  files  within  the  NTIPS  MIS  computer  network.  An 
alternative  approach  is  to  not  use  MIS,  but  create  and  maintain  an  independent  man- 
agement information  system.  Such  an  approach  would  be  applicable  to  either  a 
centralized  or  decentralized  organizational  structure.  The  advantage  of  using  the 
MIS,  particularly  in  a decentralized  organization,  is  that  it  allows  more  flexibility 
in  customizing  the  design  of  the  files  to  meet  the  unique  requirements  of  each  major 
acquisition  activity. 

The  disadvantage  of  the  independent  MIS  is  that  by  taking  the  files  out  of 
the  NTIPS  MIS  computer  network,  the  ability  of  other  functions  of  NTIPP,  such 
as  management,  to  access  this  information  has  been  eliminated.  Also,  while  there 
is  a need  for  a certain  degree  of  flexibility  in  the  structure,  it  must  be  tempered 
with  a common  approach,  or  initial  distribution  will  end  up  with  a totally  unique 
approach  for  each  major  acquisition  activity. 

Mixed  Files  Alternative  — An  additional  approach  to  information  management 
is  to  mamtain  the  existing  file  system  (mixture  of  manual  and  automated  files)  for 
collection  and  control  of  distribution  requirements.  Although  such  an  approach  would 
be  viable  from  an  economic  standpoint,  it  would  also  limit  the  function's  capability 
to  respond  in  a timely  manner. 
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Figure  4-18.  Compari.son  of  Centralized  and  Decentralized  Initial  Distribution  Control  Function. 
Proximity  to  Acquisition  activity,  to  whicli  it  must  closely  interrelate,  is  the  key  to  successful 
initial  distribution  control. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.4  - Distribution  Subsystem 

4.4.4  DESCRIPTION  OF  THE  RESUPPLY  FUNCTION 


The  goal  of  resupply  is  to  develop  a system  that  is  responsive  to  user  demands.  Taking 
TlVls  out  of  the  Navy  supply  system  and  making  them  an  integral  part  of  NTIPS  would 
provide  more  direct  control  and  a more  effective  interrelationship  with  the  user. 

Resupply  provides  the  capability  to  fill  user  requests  to  furnish  copies  of 
previously  deployed  TNls,  changes,  and  revisions.  This  is  currently  done  as  a regular 
supply  action,  and  responsiveness  to  the  user  is  often  slow.  To  the  TM  user,  respon- 
siveness is  measured  in  terms  of  how  long  it  takes  to  receive  the  manual  he  has 
requested.  In  the  current  practice,  when  a user  prepares  a TM  requisition  he  assigns 
a priority  designator  to  it.  The  designator  tells  the  resupply  function  the  latest 
calendar  day  by  which  the  TM  should  be  delivered.  For  example,  priority  designa- 
tors 1 through  3 must  be  delivered  within  8 days  for  domestic  shipments  and  12  to 
13  days  for  overseas  shipments.  Priority  designators  4 through  8 are  12  days  for 
domestic  and  16  to  17  days  for  overseas.  Priority  designators  9 through  15  are  31 
days  domestic  and  60  to  90  days  overseas,  depending  on  location.  It  should  be  kept 
in  mind  that  these  are  requested  delivery  priorities  which  are  frequently  not  met. 

The  preliminary  concept  for  the  resupply  function  would  establish  it  as  a 
single,  centralized  TM  supply  activity.  Unlike  current  methods  of  resupply,  the 
method  being  proposed  here  would  not  be  a part  of  the  Navy  supply  system,  but 
would  instead  be  a functional  part  of  the  NTIPS  Distribution  Subsystem.  This  will 
allow  the  producers  of  TMs,  i.e.,  NTIPS,  more  direct  control  of  the  supply  of  man- 
uals to  fleet  users.  It  would  provide  central  storage,  retrieval,  and  control  for  all 
Navy  TMs  in  a variety  of  media.  As  with  the  other  functional  elements  of  the  Dis- 
tribution Subsystem,  information  management,  control,  and  reporting  will  be  auto- 
mated as  an  element  of  the  NTIPS  Management  Information  System  (MIS).  Speci- 
fically, it  will  provide  the  function  with  an  automated  system  of  materials  manage- 
ment. Inventory  control  records  will  be  structured  to  reflect  TMs,  changes  and 
revisions  received,  issued,  and  on-hand  balance.  Stock  balances  will  be  maintained 
through  utilization  of  demand  forecasting  techniques  which  will  give  management 
the  visibility  to  replenish  on-hand  stock  balances  before  they  reach  minimum  levels. 
In  addition,  the  system  will  provide  reports  on  inventory  status,  stock  utilization, 
and  requisition  activity.  Such  a centralized  TM  resupply  system  will  be  more  effec- 
tive in  responding  to  user  requests  by  being  dedicated  only  to  TMs,  reducing  the 
occurrence  of  back  orders  by  having  increased  visibility  of  user  demand  trends  and 
by  lessening  the  confusion  of  where  to  send  a request.  This  increased  responsiveness 
should  be  especially  apparent  for  priority  designators  9 through  15. 

As  shown  in  the  following  work  flow  diagram  (Figure  4-19),  inventory  is 
received  as  a result  of  the  initial  deployment  of  data  by  the  TM  supply  function. 
Stock  is  received  and  inventory  control  information  is  input  to  the  MIS.  The  method 
to  be  used  for  storage  of  the  material  depends  upon  the  medium  on  which  the  TM 
is  recorded.  However,  the  storage  facility  will  be  capable  of  handling  the  paper 
and  microform  media  selected  for  the  NTIPS  preliminary  concept  and  of  incorpor- 
ating future  media  which  may  become  viable  within  the  1980s  time  frame.  The 
major  exception  to  this  is  the  direct  digital  transmission  medium,  which  would  sig- 
nificantly alter  both  the  type  of  storage  facilities  required  and  the  means  for  distri- 
bution. As  a result,  this  medium  will  be  presented  as  an  alternative  design  approach 
in  a subsequent  topic. 

All  requests  for  resupply  action  are  sent  to  one  central  location  within  the 
resupply  function.  The  inventory  is  searched  via  access  to  the  materials  manage- 
ment system.  If  the  item  is  in  stock  in  its  requested  quantity,  it  is  pulled  from  stor- 
age and  sent  to  the  requestor  via  the  best  available  means  of  transportation.  Again, 
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medium  dictates  the  packaging  method  as  well  as  the  means  of  delivery.  If  an  item 
is  not  in  stock,  the  user  is  notified  immediately  and  the  request  is  placed  on  back 
order. 


Back  orders  require  that  immediate  action  be  taken  to  replenish  stock  to 
acceptable  levels.  In  addition,  the  MIS  will  be  designed  to  look  at  current  stock 
on  hand  and  past  demand  history  to  forecast  minimum/rnaximum  stock  levels. 

Stocks  reaching  the  minimum  on-hand  balance  level  cause  replenishment  action 
to  be  undertaken.  Replenishment  action  involves  issuing  a directive  to  the  archive 
function  to  pull  the  TM  master  from  its  files  and  forward  it  to  a designated  replica- 
tion function.  The  replication  function  will  be  directed  to  produce  TMs  in  a desig- 
nated quantity  and  send  them  to  the  resupply  function.  The  TM  master  will,  if  ap- 
plicable, be  returned  to  the  archive  function.  Once  replenishment  stock  is  received, 
back  orders  will  be  filled  in  the  most  expedient  manner. 


1 

I 

[ 

[■ 

i 


Figure  4-19. 
responds  quii 


Figure  4-19.  The  Resupply  Preliminary  Concept.  Tlie  goal  of  resupply  is  to  develop  a system  that 
responds  quickly  and  efficiently  to  user  requests  for  TMs,  changes,  and  revisions. 
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StM'tiol’,  1 - Subsyste-ii  Prelitninary  Conc'cpts  atui  Alternatives 
SiiDseetion  4.4  - Distribut ion  Subsystem 

4.1.5  DCSi'ltlP  riON  Ol'  KI'SUPPI.Y  FUN(''riON  M.I'K KN  A I'lVES 


Although  the  decentralisation  alternative  could  result  in  a more  responsive  resupply 
(unction  with  conventional  printed  paper  FMs,  its  advantages  are  dirninished  as  more 
advanced  media  are  utilise;!  and  tnateria!  movement  becomes  less  of  a critical 
consideration. 

The  two  major  ureas  of  concern  in  the  formulation  of  alternative  approaches 
to  the  resupply  function  are  organisational  structure  and  media,  flic  organisational 
question  to  be  answered  is  whether  it  is  more  effective  to  have  a centralised  or 
decentralised  resupply  function.  Regardless  of  the  organisational  structure,  how- 
ever, media  can  have  a direct  impact  on  the  ability  of  the  resupply  function  to  be 
responsive  to  user  requests. 

There  are  several  ways  to  accomplish  decentralisation  of  the  resupply  func- 
tion. l-’irst,  the  T\1  requiremetits  of  the  various  major  acquisition  activities  could 
be  determined  and  the  supply  function  separated  along  geographical  detnand  lines. 

In  this  situation  there  would  be,  for  instance,  a major  resupply  function  on  each 
coast  and  in  the  r,reat  bakes  area,  bach  would  have  the  capability  of  supplying 
all  of  the  T'vl  needs  in  its  area.  Another  consideration  would  be  to  divide  the  TM 
resupply  responsibilities  among  the  various  equipment  types.  For  instance,  aviation 
would  have  its  ov;:i  supply,  as  would  shipboard  electronics,  mechanical  equipments, 
etc.  Another  approacli  is  to  make  each  major  acquisition  activity  responsible  foi' 
its  own  resupply. 

If  resupply  is  dece?Uralizcd,  there  is  an  additional  organ! /mtional  decision 
which  must  be  made.  That  is;  whether  these  functions  should  be  a part  of  the  Nl'lPS 
org;mi/.ational  structure  dedicated  to  a specific  acquisition  activity  or  a part  of 
the  acquisition  activity  itself.  Additionally,  consideration  must  be  given  to  the 
resupply  function  being  a part  of  the  Naval  supply  system  as  it  is  now,  even  though 
it  is  decentrali/.ed. 

Uith  the  use  of  paper  as  one  of  today's  TM  media,  consideration  must  be 
given  to  the  bulk  and  weight  of  the  mat"-rial  to  be  moved.  But  current  projections 
of  the  media  to  be  used  in  the  198()s  suggest  that  microforms,  disc  memory,  video 
disc,  and  other  advanced  media  will  replace  paper.  As  the  end-products  of  these 
media  are  significantly  stnullcr  and  lighter  than  paper,  shipping  becomes  less  of 
a critical  problem.  Hence,  the  need  for  placing  the  source  of  supply  close  to  the 
user  is  tli minished.  In  addition,  decentrali/.ed  storage  facilities  would  require  that 
all  of  the  functions  and  capabilities  of  resupply  be  duplicated,  both  manpower  and 
equipment,  at  each  location. 

A considered  alternative  is  linked  to  the  development  of  a digital  TM  data 
base  for  the  working  archive.  Providing  on-demand  replication  devices  that  are 
driven  by  digital  tapes  would  effectively  eliminate  the  need  to  physically  store 
copies  of  TMs.  When  a request  is  received  for  a TM,  a tape  is  made  from  the  digital 
data  in  the  working  archive  and  used  to  drive  the  replication  device  (which  is  similar 
to  a "Xerox’"  inachine),  and  the  copy  vmuld  then  be  sent  to  the  requester. 

Another  alternative,  which  would  take  full  advantage  of  media  advances, 
is  to  utili/.c  a direct  digital  system  of  T'vl  storage  and  retrieval.  Such  a system  would 
involve  putting  all  TMs  in  the  Navy's  inventory  into  mass  memory  storage,  which 
would  significantly  alter  the  organization  and  operation  of  resupply  (see  Figure  4-20). 
Output  from  the  content  generator  would  be  transmitted  directly  in  digital  form 
to  a central  storage  facility  through  the  entry  and  processing  subfunctions  of  the 
Publishing  Subsystem.  The  initial  distribution  function  would  remain  basically  the 
same,  but  instead  of  issuing  shipping  directives  to  a replication  activity,  it  would 
issue  trails  nission  instructions  to  central  storage.  These  instructions  would  tell 
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the  central  storage  activity  where  to  transmit  the  newly  acquired  Tivl.  This  would, 
of  course,  require  digital  receiving  equipment  at  each  user  location  as  well  as  some 
sort  of  replication  capability. 

The  major  impact  of  the  direct  digital  system  on  the  Distribution  Subsystem 
is  that  it  does  away  with  the  need  for  the  resupply  and  archive  functions  as  they 
have  been  previously  defined.  Resupply  becomes  the  central  storage  facility,  thus 
eliminating  the  requirement  for  a working  archive.  There  is  no  need  for  a replen- 
ishment activity  because  the  T!V1  master  is  stored  in  digital  form  and  never  leaves 
the  facility.  The  historical  archive  would  still  be  needed,  but  this  would  probably 
take  the  form  of  a backup  memory  used  only  in  the  event  of  failure  in  the  central 
storage. 

The  ability  to  implement  such  a system  is  limited  by  the  technical  develop- 
ment of  mass  memory  devices  which  are  capable  of  handling  the  amount  of  storage 
required.  It  is  estimated  that  such  a file  would  be  as  large  as  129  trillion  bits.  The 
subject  of  muss  memory  storage  devices  is  discussed  in  more  detail  in  a subsequent 
topic. 

An  additional  alternative  is  to  leave  the  resupply  function  as  it  is  today, 
residing  in  one  principal  location  as  a part  of  the  Naval  supply  system.  This  would 
take  full  advantage  of  existing  resources  and  would  cause  very  little  disruption  in 
resupply  operation  during  the  implementation  of  NTIPS. 


Figure  4-20.  The  Resupply  Function  in  a Digital  Environment.  In  the  digital  medium,  the  central 
storage  function  assumes  the  role  of  resupply  attd  working  storage. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.4  - Distribution  Sybsystem 


4.4.6  DESCRIPTION  OF  THE  ARCHIVE  FUNCTION 


A distributed  working  archive  coupled  to  a centralized  historical  archive  controlled 
through  the  MIS  are  combined  for  the  archive  function  in  the  preliminary  system  concept. 

The  initial  concept  of  the  archive  function  would  establish  capabilities  for 
the  storage,  retrieval,  and  control  of  all  masters  and  master  records  of  TMs  deployed 
by  the  Navy.  The  archive  function  would  consist  of  a historical  and  a working  ar- 
chive. The  historical  archive  will  provide  for  the  storage  and  accountability  of  the 
physical  TM  masters  for  every  new  or  updated  TM.  The  working  archive  will  be 
primarily  a digital  data  base  only  for  the  active  TMs  in  the  Navy's  inventory.  It 
would  be  used  for  replenishment  of  resupply  stock  or  update  of  existing  TMs  without 
disturbing  the  historical  archive. 

Since  TMs  are  produced  in  somewhat  limited  quantities  based  on  projected 
near  future  usage,  TM  resupply  activities  must  be  capable  of  replenishing  their  stock 
when  the  on-hand  balance  is  near  depletion.  To  speed  reproduction,  all  the  plans 
and  specifications  needed  to  reproduce  a TM  would  be  included  with  the  TM  master 
copy  in  the  archive.  Thus,  all  that  will  be  needed  to  replenish  stock  is  to  retrieve 
the  TM  master  copy  and  send  it  through  a replication  process.  This  would  apply 
equally  when  changes  or  revisions  are  required.  Since  it  is  far  more  efficient  to 
change  or  revise  an  existing  master  than  to  recreate  it  in  its  entirety,  the  ability 
to  access  archival  data  is  critical  to  the  design  of  a responsive  system. 

Organizationally,  the  two  archives  would  be  subfunctions  of  the  Distribution 
Subsystem  (see  Figure  4-21).  The  historical  archive  would  be  placed  in  a single  lo- 
cation with  a centralized  management  structure  directing  its  activities.  The  working 
archive  would  also  be  directed  by  a centralized  management  structure,  but  the  ac- 
tual data  would  be  dispersed  geographically,  by  commodity  or  other  factor.  Control 
would  be  provided  through  the  NTIPS  MIS. 

Working  Archive  - The  initial  loading  of  the  working  archive  data  base  with 
TMs  received  from  contractor  or  prepared  by  Navy  content  generators  is  through 
the  digital  production  function  of  the  Publishing  Subsystem.  This  input  and  any 
subsequent  moving  of  TMs  to  be  reprocessed  between  the  Publishing  Subsystem  and 
the  working  archive  is  controlled  through  MIS.  Not  only  does  MIS  coordinate  the 
transfer  and  use  of  the  TM  data  base,  but  MIS  also  provides  NTIPS  with  access  to 
an  index  of  information  on  any  active  TM  in  the  Navy.  The  index  would  cover  TM 
type,  equipment  nomenclature,  date  of  issue,  and  other  relevant  indexing  informa- 
tion. This  would  include  a cross-referencing  capability  to  enable  users  to  locate 
TMs  by  other  than  the  official  TM  number.  The  technology  to  be  applied  in  the 
preliminary  concept  for  the  working  archive  is  discussed  in  the  following  topic. 

Traditionally,  the  TM  data  base  resides  in  the  Navy.  Although  it  would  be 
distributed  (by  mission,  commodity,  etc.),  it  would  still  be  within,  as  well  as  con- 
trolled by,  the  NTIPS  organizational  structure.  Undoubtedly,  when  a contractor 
delivers  a TM  via  digital  tape,  he  would  maintain  his  original  TM  data  base  to  sup- 
port subsequent  work  efforts.  The  contractor  can  anticipate  update  work  on  that 
TM,  or  utilizing  the  data  base  to  support  other  customers  or  other  similar  products. 
The  principal  Navy  subsequent  effort  is  TM  update  which,  under  the  data  base  con- 
cept, could  be  all  updates  after  the  original  TM  is  issued. 

It  is  essential  for  the  working  archive  to  work  closely  with  the  historical 
archive  to  maintain  integrity  of  the  two  data  bases  and  the  TM  data  index.  The 
prime  example  of  interplay  between  the  two  archives  is  when  TMs  from  the  working 
archive  are  returned  from  an  update  processing  by  Publishing.  That  TM  update  pack- 
age must  immediately  be  entered  into  the  historical  archive  and  the  index  corrected. 
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Historical  Archive  - New  TMs  are  sent  to  the  historical  archives  from  the 
Publishing  Subsystem.  As  the  subfunction  is  primarily  a materials  management 
activity,  it  is  subject  to  the  same  type  of  control  and  requirements  as  the  resupply 
function.  Here,  as  in  the  resupply  function,  the  N flPS  management  information 
system  (MIS)  computer  network  will  be  used  for  creation  and  maintenance  of  re- 
cords for  control  of  the  TM  masters. 

Physical  storage  procedures  will  depend  upon  the  media  in  which  the  masters 
have  been  produced.  If  in  a condensed  form,  such  as  microfiche  or  roll  microfilm, 
the  masters  will  be  stored  in  that  medium.  If,  however,  the  masters  require  bulk 
storage,  such  as  reproducible  masters  for  paper  manuals,  they  will  be  converted 
to  a more  condensed  medium  for  storage  in  the  historical  archive  files.  An  addi- 
tional concern  of  this  function  is  the  assurance  that  the  materials  are  stored  in  a 
(nanner  that  will  assure  their  protection.  Consideration  must  be  given  to  how  the 
different  media  withstand  storage  for  prolonged  periods  of  time,  including  require- 
ments for  control  of  light,  temperature,  and  humidity. 

Since  the  historical  archive  is  a record  of  Navy  TMs,  both  active  and  inac- 
tive, it  will  be  used  as  a backup  source  of  information  for  the  working  archive. 

In  the  event  such  a need  occurs,  the  historical  archive  master  will  be  retrieved  for 
transfer  to  the  working  archive  and  subsequent  processing  by  the  Publishing  Subsystem. 
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Pigurc  4-21.  NTIPS  Archive  Function.  Tlie  archive  function  would  have  two  subfunctions:  working 
and  historical.  Primarily  digital,  the  working  archive  would  store  active  TMs.  while  the  historical 
archive  would  be  the  physical  repository  for  all  TM  masters. 


Section  4 - Subsystem  Preliminary  Concept  and  Alternatives 
Subsection  4.4  - Distribution  Subsystem 

4.4.7  DIGITAL  ARCHIVE  TECHNOLOGY  CONSIDERATIONS 


To  store  the  Navy  TM  data  base  in  the  working  archive  will  require  the  development 
of  a mass  memory  storage  capability  for  up  to  129  trillion  bits.  Current  technological 
developments  in  memory  storage  devices  show  promise  of  the  feasibility  for  storing 
such  amounts  of  data  within  5-10  years. 

The  preliminary  concept  of  the  archive  function  would  establish  a data  base 
in  the  working  archive  subfunction,  for  all  active  TMs.  The  working  archive  would 
serve  as  the  primary  source  of  information  for  updating  TMs  and  also  be  the  source 
for  TM  masters  for  replenishing  resupply  stock.  Functionally,  the  data  base  is  all- 
digital,  with  automated  control  mechanisms  provided  through  the  NTIPS  Manage- 
ment information  system  (MIS)  computer  network. 

Storage  methods  and  techniques  are  key  considerations  for  the  development 
of  a usable  working  archive.  Storage  technology  has  been,  and  continues  to  be,  a 
developmental  area.  A very  large  storage  capacity  is  needed  for  the  TM  data  base. 
For  example,  the  present  inventory  of  technical  manuals  would,  as  digital  bits,  need 
over  one  million  hard  discs.  Although  the  potential  amount  of  digital  storage  be- 
comes very  large  when  pages  are  converted  to  bits  (see  Table  4-14),  the  present 
technology  indicates  low-cost,  high-capacity  storage  will  be  available  in  the  1980- 
1985  time  frame.  Chief  among  the  viable  digital  storage  candidates  are  the  bubble 
memory,  charge-coupled  devices,  video  discs,  and  holograms. 

The  magnetic  bubble  memory  is  already  being  marketed  with  10^  bits  per 
6-centimeter  square  chip.  Chips  with  109  bit  capacity  will  be  available  by  1980. 
Using  bubble  technology,  the  present  inventory  could  be  accommodated  on  10,000 
one-millimeter  square  109  chips.  Present  per-bit  cost  is  high,  but  significant  cost 
reductions  are  projected  as  the  higher  density  chips  (up  to  10l2)  are  developed. 

One  significant  attribute  of  magnetic  bubble  memories  is  that  they  are  indestruct- 
able  and  transportable,  making  them  a potential  candidate  for  applications  where 
digital  hologram  or  digital  video  discs  are  considered. 

The  charged-coupled  devices  (CCDs),  although  a totally  different  technol- 
ogy, are  similar  to  bubbles  in  their  high  storage  capacity  for  small  sizes.  Again, 
the  present  cost  is  relatively  high,  but  is  continuing  to  come  down  as  development 
effort  increases.  Unlike  bubbles,  the  CCD  is  not  permanent  - in  use,  a power  failure 
could  destroy  the  data  stored  in  a CCD. 

The  video  disc  used  for  digital  storage  is  a relatively  cheap  (per  bit)  device, 
and  the  digital  hologram  is  also  in  that  category.  The  video  disc  is  described  in 
the  DTNSRDC  report  1 and  holograms  in  the  Task  1 report2  page  3-254.  These  stor- 
age media  are  also  candidate  media  for  delivery  of  the  TM  to  the  user  and  for  use 
in  his  environment.  Another  candidate  for  digital  storage,  which  is  simitar  to  the 
video  disc  and  wilt  be  considered  along  with  it,  is  the  metal  film  medium. 

Further  analysis  may  show  that  a continual  assessment  of  technology  will 
be  needed  in  the  field  of  storage  media.  As  with  delivery  and  user  (presentation) 
media,  there  are  sufficient  developments  to  warrant  continual  in-depth  invest iga 

tions  and  evaluations  through-out  the  design  process  of  an  NTIP  System,  and  

Choices  will  have  to  be  made  at  certain  points  in  the  design  process,  but  rrnli-’  • 
some  options  must  also  remain  open. 

^Poe  Engineering  Services;  Photographic  Video  Disc  Techiv)log>  - 
1976,  David  Taylor  Naval  Ship  Research  and  Development  'eni.  - 

2 

Hughes  Aircraft  Company;  Task  1 Report  (t'DRL  AOOl)  ■ , 

Proposed  lechnical  Manual  Systems;  24  March  1977,  Dh\  ■ 

Research  and  Development  Center, 
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TABLE  4-14.  NAVY  TMs  CONVERTED  FROM  PAGES  TO  DIGITAL  BITS 
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Basis  for  Conversion 

Text  Page  = 20,000  to  40,000  Bits 

Art  Page  (Uncompressed)  = 1,000,000  to  16,000,000  Bits 

Art  Page  (Compressed)  = 100,000  to  1,600,000  Bits 

Total  TM  Inventory 

Low  Estimate 

High  Estimate 

Text 

348,000,000,000  - 

696,000,000,000 

Bits 

Art 

800,000,000,000  - 

128,000,000,000,000 

Bits 

1,148,000,000,000  - 

128,696,000,000,000 

Bits 

(Total  = 1 Trillion  to 

129  Trillion  Bits) 

Yearly  New 

TM  Production 

Text 

42,000,000,000  - 

84,000,000,000 

Bits 

Art 

900,000,000,000  - 

14,400,000,000,000 

Bits 

942,000,000,000  - 

14,484,000,000,000 

Bits 

(Total  = 942  Billion  to  15  Trillion  Bits) 

Yearly  Update 

Text 

4,080,000,000  - 

12,680,000,000 

Bits 

Art 

12,600,000,000  - 

3,168,000,000,000 

Bits 

16,680,000,000  - 

3,180,680,000,000 

Bits 

(Total  = 17  Billion  to 

3 Trillion  Bits) 

Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.4  - Distribution  Subsystem 


4,4.8  DESCRIPTION  OF  ARCHIVE  FUNCTION  ALTERNATIVES 


There  are  several  alternative  approaches  to  the  archive  that  relate  to  various  combina- 
tions of  the  two  subfunctions  (working  and  historical)  as  the  result  of  centralized  and 
decentralized  options.  All  combinations  are  usable,  but  they  are  not  equally  effective. 

Alternative  approaches  to  the  archive  function  are  primarily  a question 
of  whether  it  would  operate  more  effectivly  in  a centralized  or  decentralized  mode. 
The  preliminary  concept  is  an  organizationally  centralized  function  with  both  the 
working  and  historical  archive  subfunction  under  the  direction  and  control  of  the 
NTIPS  Distribution  Subsystem. 

There  are  a number  of  viable  alternatives  to  this  approach.  First,  the  entire 
function  can  be  decentralized  by  either  (a)  combining  the  working  and  historical 
archives  into  a single  archive,  or  (b)  by  utilizing  the  functions  as  they  appear  in 
the  preliminary  concept  (see  Figure  4-22,  reference  la  and  lb).  Another  alternative 
(reference  2 in  Figure  4-22)  is  to  develop  a combination  approach,  that  is,  a cen- 
tralized historical  archive  and  a decentralized  working  archive.  The  last  alternative 
(reference  3 in  Figure  4-22)  would  be  to  utilize  the  centralized  approach,  combining 
the  working  and  historical  archives  into  a single  activity. 

In  the  first  alternative  (reference  la),  the  archive  files  would  be  split  up 
and  assigned  to  those  major  acquisition  activities  that  have  cognizance  over  the 
creation  and  maintenance  of  the  basic  manual  and  its  subseqent  revisions  and 
changes.  The  need  for  a separate  working  archive  would  be  eliminated  since  master 
copies  of  the  TMs  would  be  readily  available  for  use  at  the  activity's  location.  Any 
requirements  for  reporting  activity  or  status  of  these  individual  files  could  still 
be  accomplished  through  the  NTIPS  Management  Information  System  (MIS)  computer 
network. 

In  reference  lb  of  the  first  alternative,  the  working  archive  concept  could 
be  retained,  but  since  there  would  be  no  central  data  base,  each  major  acquisition 
activity  would  require  all  the  hardware  capability  of  every  other  activity.  Both 
of  the  decentralized  alternative  approaches  are  redundant  and  subject  to  control 
problems  from  a system  point  of  view. 

The  second  alternative  (reference  2)  is  to  utilize  a combination  of  the  cen- 
tralized and  decentralized  organization  structures.  In  this  approach,  the  historical 
archive  would  remain  a centralized  repository  for  all  Navy  TM  masters  and  be  under 
the  direction  and  control  of  the  NTIPS  Distribution  Subsystem.  The  working  archive 
would  then  be  decentralized  under  the  control  and  direction  of  the  major  acquisition 
activities  as  described  in  the  first  alternative.  Such  an  approach  would  have  the 
effect  of  allowing  the  individual  activities  to  design  their  TM  archives  to  meet  their 
own  unique  requirements,  while  still  providing  a central  repository  for  information 
for  all  Navy  TMs.  Again,  status  and  activity  reporting  of  the  various  files  could 
be  maintained  through  MIS,  which  could  provide  the  inventory  control  and  accounta- 
bility capabilities  to  the  historical  archive. 

The  last  alternative  (reference  3)  would  be  to  utilize  a centralized  struc- 
ture, but  eliminate  the  two  subfunctions.  In  such  an  approach,  the  archive  function 
would  simply  be  a repository  for  all  TM  masters  that  could  be  accessed  from  one 
central  location  by  any  user  who  has  a need  for  the  material.  Like  a storage  ac- 
tivity, it  would  essentially  provide  those  capabilities  necessary  for  the  accurate 
control  and  accountability  of  archival  material.  It  would  be  a most  economical 
and  simple  approach  to  take. 

The  major  problem  with  any  approach  that  involves  decentralization  of  the 
archive  lies  in  the  fact  that  by  distributing  the  files  into  various  locations  the  con- 
trol and  accountability  becomes  more  complicated.  Unless  these  files  are  netted 
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in  some  fashion,  the  ability  to  construct  a cross-referenced  data  file  is  lost.  This 
could  result  in  a situation  such  as  exists  today  wherein  Navy  TM  masters  are  spread 
over  a variety  of  physical  locations,  and  no  one  organization  or  activity  knows  what 
is  available  or  where  it  can  be  found.  Additionally,  any  alternative  that  eliminates 
the  need  for  a digital  working  archive  data  base  will  require  the  physical  removal 
of  TIV]  master  materials.  Such  removals  complicate  accountability  controls  and 
contribute  to  precious  materials  being  misplaced,  damaged,  or  destroyed. 


Figure  4-22.  Alternative  Organizational  Placements  of  the  Archive  Function.  In  some  alternative 
approaches  the  working  and  historical  archive  subfunctions  are  combined. 
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4.5.1  OVERVIEW  OF  MANAGEMENT  SUBSYSTEM  PRELIMINARY  CONCEPT 


The  NTIPS  Management  Subsystem  utilizes  a central  system  management  function  to 
provide  direction  and  guidance  to  decentralized  operational  management  functions.  To 
integrate  these  functions  into  the  existing  Navy  structure,  they  are  operated  as  part 
of  NTIPS,  but  are  dedicated  to  the  TM  requirements  of  the  major  acquisition  activities. 

The  NTIPS  Management  Subsystem  is  analogous  to  a standard,  two-level 
corporation  structure.  The  first  NTIPS  management  level  operates  as  a "corporate 
management  group"  providing  policies  and  directives  for  the  overall  operation  of 
the  system.  The  second  management  level  resides  at  each  of  the  "corporate  oper- 
ating divisions"  that  produce  the  actual  TMs.  There  is  one  second-level  management 
function  dedicated  to  the  TM  needs  of  each  major  acquisition  activity,  but  it  is  or- 
ganizationally a part  of  NTIPS  and  will  have  budgets  and  staffing  reviewed  by  the 
first  management  level. 

A strong,  centralized  first-level  NTIPS  management  function  is  necessary 
to  provide  overall  Navy-wide  policy  guidance  to  NTIPS  and  eliminate  fragmented 
approaches  to  TM  procurement/production.  This  function  is  established  at  a first 
management  level  so  that  NTIPS  has  a single  point  from  which  uniform  overall  man- 
agement guidance  is  provided  to  major  acquisition  activities  in  TM  matters. 

As  shown  in  Figure  4-23,  the  first-level  NTIPS  management  function  com- 
prises four  subfunctions.  The  NTIP  System  management  subfunction  is  responsible 
for  the  overall  management  of  NTIPS,  and  establishes  and  promulgates  all  policies 
and  directives  necessary  for  system  operation.  The  system/product  improvement 
engineering  subfunction  performs  in-depth  analyses  of  budgeting  and  scheduling  data 
from  Navy-wide  NTIPS  activities,  analyzes  TM  product  quality,  provides  the  engi- 
neering expertise  for  changes  to  NTIP  System  technology  or  design,  and  prepares  all 
quality  assurance  policies  for  the  NTIP  System.  The  research  and  development  (R&D) 
subfunction  coordinates  all  Navy  NTIPS-related  R&D  efforts  and  maintains  contacts 
with  on-going  DoD  and  industry  TM  R&D  efforts.  The  cost  analysis/forecasting  sub- 
function maintains  a comprehensive  data  base  of  cost  breakdowns  for  specific  ac- 
tivities of  NTIPS,  and  also  assists  with  budget  reviews  and  long  range  planning  and 
forecasting. 

The  second-level  NTIPS  operations  functions  are  separated  and  dedicated 
to  the  major  acquisition  activities  in  order  to  provide  for  more  effective  considera- 
tion of  activity-unique  TM  requirements  (e.g.,  environment,  personnel,  equipment, 
etc.).  In  addition,  separating  the  second-level  NTIPS  operations  functions  into  dedi- 
cated units  controls  the  size  of  the  functions  and  simplifies  user  access  to  the 
functions. 

Each  NTIPS  operations  management  function  is  responsible  for  implementing 
the  policies  established  by  the  first  management  level  and  for  establishing  detailed 
operating  procedures  that  coordinate  the  remaining  NTIPS  subsystems  during  the  pro- 
curement and  production  of  TMs.  Normal  operating  funds  are  routed  via  the  first 
management  level  to  the  second  level  and  thence  to  other  activities  assigned  to 
NTIPS  control  (e.g.,  TM  Acquisition  Subsystem).  The  funds  for  TM  projects  are  sepa- 
rated according  to  equipment  status  — in-production  or  out-of-production.  The  funds 
for  in-production  TMs  are  identified  and  budgeted  during  the  early  phases  of  the  hard- 
ware acquisition  process  by  the  system  acquisition  process  program  manager  (PM)  and 
are  transferred  to  the  cognizant  second-level  NTIPS  Operations  Management  subfunc- 
tion at  program  inception.  Out-of-production  TM  funds  are  used  for  updates  that  are 
initiated  by  the  second-level  feedback  and  update  subfunction  and  budgeted  from 
O&MN  funds.  The  second-level  NTIPS  Operations  Management  subfunction  receives 
this  O&MN  funding  directly  and  is  responsible  for  the  TM  efforts  on  out-of-production 
TMs. 
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As  shown  in  Figure  4-23,  the  NTIPS  operations  management  function  com- 
prises six  subfunctions.  The  NTIPS  Operations  Management  Subfunction  is  responsible 
for  implementing  the  first-level  policies  and  directives,  promulgating  detailed  oper- 
ating procedures  to  its  NTIPS  activities,  and  guiding  the  operations  of  the  NTIPS  ac- 
tivities within  its  purview  The  practices  and  procedures  subfunction  prepares  the 
detailed  operating  procedures  and  maintains  the  manuals  containing  the  procedures, 
and  the  first-level  policies.  The  Management  Information  System  (MIS)  subfunction 
maintains  a data  base  of  pertinent  information  covering  TM  operations  and  costs,  a 
TM  configuration  index  of  all  assigned  users,  and  a listing  of  user  feedback  action 
items.  MIS  also  provides  weekly  cost  and  operations  reports  to  support  the  daily  oper- 
ations of  the  NTIPS  subsystems  - TM  Acquisition,  Content  Generation  (Navy  only). 
Publishing,  and  Distribution.  MIS  also  supplies  a periodic  report  for  use  by  the  Man- 
agement Subsystem  in  evaluating  the  overall  performance  of  NTIPS. 

The  configuration  accounting  subfunction  manages  the  numbering  of  TMs 
and  maintains  the  user  configuration  index.  The  feedback  and  update  subfunction 
manages  the  user  feedback  network  and  initiates  updates  of  out-of-production  TMs. 
The  cost  monitor/evaluation  subfunction  periodically  receives  from  MIS  operational 
data  concerning  the  NTIPS  activities  and  evaluates  the  performance  of  specific  TM 
projects. 


Figure  4-23.  The  NTIPS  Management  Subsystem.  A two-tiered  management  structure  provides  overall 
management,  policies,  and  directives  from  a centralized  function  and  operational  management  from 
functions  responsible  to  NTIPS  but  dedicated  to  the  major  acquisition  activities. 
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Section  4 - Subsystem  Preliminary  Concepts  and  Alternatives 
Subsection  4.5  - Management  Subsystem 

4.5.2  DESCRIPTION  OF  THE  NTIP  SYSTEM  MANAGEMENT  FUNCTION 


The  overall  direction  of  NTIPS  is  provided  by  policies  and  directives  established  by  the 
NTIP  System  Management  Subfunction.  

The  primary  NTIPS  coordinator  is  the  NTIP  System  Management  Subfunction, 
which  also  evaluates  overall  system  performance  and  product  quality.  The  subfunc- 
tion establishes  NTIPS  goals,  assures  proper  functioning  of  NTIPS,  and  provides  long 
range  planning.  The  subfunction  will  also  maintain  working  relationships  with  high 
level  representatives  from  Navy,  DoD,  and  industry  in  order  to  coordinate  NTIPS 
overall  policy  and  doctrine  with  these  activities.  In  addition,  the  System  Management 
Subfunction  will  review  all  staffing  and  budgeting  requests  for  the  NTIP  System  and 
be  responsible  for  distribution  of  operating  funds.  Table  4-15  lists  the  activities  of 
the  subfunction  along  with  the  other  subfunctions  and  their  activities,  which  are  ex- 
plained in  more  detail  in  the  following  paragraphs. 

The  system/product  improvement  engineering  subfunction  fills  the  need 
for  a continuing  check  of  the  effectiveness  of  the  system  design  and  the  quality 
of  finished  TMs.  An  analysis  of  the  budgets  and  schedules  of  the  TM  operations  of 
each  major  acquisition  activity  (input  from  the  separate  NTIPS  operations  manage- 
ment functions)  would  provide  data  that  could  be  used  to  compare  the  operations 
of  the  major  acquisition  activities  and  to  recommend  possible  changes  in  system 
design  that  could  improve  performance.  TM  quality  would  be  reviewed  based  on 
user  feedback  reports,  and  the  subfunction  would  modify  quality  assurance  (QA) 
policies  as  required  to  improve  the  TM  product. 

The  system/product  improvement  engineering  subfunction  would  also  be 
responsible  for  designing  and  implementing  system  changes  based  on  new  technol- 
ogies found  feasible  by  the  research  and  development  subfunction  and  would  estab- 
lish proper  measures  of  effectiveness  to  evaluate  the  changes.  In  addition,  the  sub- 
function would  assist  the  TM  Acquisition  Subsystem  with  specification  development 
for  new  products  or,  when  required,  for  modifications  to  the  system  design.  The 
subfunctions  would  also  be  responsible  for  the  control  of  new  TM  element  design, 
update  of  user-data  match  criteria,  and  the  tradeoff  of  training/teehnical  manual 
requirements. 

The  research  and  development  (R&D)  subfunction  would  be  established  at 
the  first  management  level  to  prevent  duplication  of  Navy  TM-related  R<5cD  efforts 
and  to  establish  goals  and  initiate  studies.  Presently,  individual  projects  are  ini- 
tiated by  activities  outside  R&D  organizations  with  varying  degrees  of  resources 
and  management  attention,  while  many  innovations  have  been  developed  by  other 
DoD  services  with  little  or  no  Navy  participation  or  consideration.  The  R&D  sub- 
function would  review  and  coordinate  all  NTIPS-related  Navy  R<5cD  efforts,  and 
maintain  contact  with  R&D  efforts  of  industry  and  DoD.  This  subfunction  would 
perform  a continuing  investigation  and  assessment  of  the  R<5cD  efforts  in  human 
engineering,  hardware  technology,  media  technology,  and  logistic  support  technol- 
ogy. The  R<5cD  subfunction  would  evaluate  new  developments  applicable  to  NTIPS 
and  recommend  cost/performance-effective  technologies  for  system  incorporation 
by  the  system/product  improvement  engineering  subfunction. 

The  cost  analysis/forecasting  subfunction  would  provide  cost  data  to  allow 
auditing  the  TM  costs  incurred  during  a system  acquisition.  At  present,  TM  costs 
are  seldom  budgeted  as  separate  line  items,  making  any  submission  of  TM  budget 
data  unreliable  and  precluding  any  valid  tradeoff  decision  between  TMs  and  other 
programs.  This  subfunction  would  maintain  a valid  product  cost  data  base,  including 
a breakdown  of  specific  facets  of  each  NTIPS  activity.  Cost  information  would 
be  input  from  the  NTIPS  operations  functions  at  the  different  major  acquisition 


activities.  In-depth  analysis  of  the  cost  data  would  establish  the  impact  of  TMs 
on  weapon  system  life-cycle  costs  and  assist  in  evaluating  system  operations. 


TABLE  4-15.  NTIP  SYSTEM  MANAGEMENT  FUNCTION 


NTIP  System  Management  Subfunction 

o Overall  Manager  of  NTIPS 
o Evaluator  of  NTIPS  Performance 

• Coordinator  of  NTIPS  Elements 

• Coordinator  of  NTIPS  with  Navy/DoD/Industry 

• Long  Range  Planning 

• NTIPS  Budgeting  and  Staffing  Review 

• Controller  of  NTIPS  Policies/Directives 

System /Product  Improvement  Engineering  Subfunction 

• NTIPS  Design  Control 

• Implementation  Design  of  New  Technology 

• Establish  Quality  Assurance  Policies 

• Coordinate  TM  Element  Design,  User-Data  Match 
Update,  Tradeoff  of  Technical  Data/Training  Needs 

• Assist  with  New  Specifications 

Research  and  Development  Subfunetion 

• Coordinate  Navy  NTIPS-Related  R&D  Efforts 

• Maintain  DoD/Industry  R&D  Contact 

• Evaluate  Efforts  in  Human  Engineering,  Media 
Technology,  Hardware  Technology 

Cost  Analysis/Forecasting  Subfunction 

• Upkeep  of  Navy-wide  NTIPS  Cost  Data  Base 

• Perform  Cost  In-Depth  Analysis 

• Establish  TM  Impact  on  Weapon  Life-Cycle  Costs 

• Assist  with  NTIPS  Cost  Evaluation 


} 


: 
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4.5.3  DESCRIPTION  OF  NTIPS  OPERATIONS  MANAGEMENT  FUNCTION 


An  NTIPS  operations  management  function  is  dedicated  to  each  major  acquisition  activ- 
ity to  provide  guidance  and  support  to  the  NTIPS  activities  procuring  and  producing 
TMs.  

The  NTIPS  operations  management  function  provides  a dedicated,  reactive 
management  group  that  is  established  at  the  major  acquisition  activity  level  and 
is  responsible  for  all  the  TM  needs  of  that  activity.  This  approach  to  TM  manage- 
ment allows  flexibility  in  the  detailed  planning  and  development  of  TMs  dictated 
by  the  mission-unique  combinations  of  personnel,  equipment,  and  environment  in- 
herent to  the  activity.  Although  dedicated  to  its  major  acquisition  activity,  the 
operations  management  function  is  a part  of  NTIPS  and  is  directly  responsible  to 
the  first-level  NTIPS  management  function. 

NTIPS  Operations  Management  Subfunction  - This  subfunction  provides  cen- 
tral management  and  guidance  for  the  day-to-day  operation  of  the  NTIP  System. 

Each  NTIPS  Operations  Management  Subfunction  establishes  and  promulgates  de- 
tailed operating  procedures  for  the  NTIPS  subsystems  [TM  Acquisition,  Content  Gen- 
eration (Navy  only).  Publishing,  and  Distribution]  that  have  been  tasked  to  provide 
TMs  for  its  major  acquisition  activity.  Each  of  these  subfunctions  has  the  responsi- 
bility of  coordinating  with  the  System  Acquisition  Process  program  manager  to 
establish  TM  budget  limits,  and  then  for  controlling  and  distributing  the  TM  funds  to 
NTIPS  activities  after  program  inception.  Each  management  subfunction  has  overall 
responsibility  for  the  delivered  TM  products  as  well  as  the  operational  efficiency  and 
cost  effectiveness  of  the  NTIPS  activities  within  its  purview. 

Management  Information  System  Subfunction  - The  Management  Information 
System  (MIS)  subfunction  answers  the  need  for  a comprehensive  data  base  that  con- 
tains specific  information  about  all  facets  of  the  NTIPS  operation.  Each  operations 
management  function  maintains  an  MIS  that  contains  data  pertinent  to  the  NTIPS 
operations  of  its  particular  major  acquisition  activity.  MIS  provides  this  information 
in  report  form  to  support  daily  TM  operation  within  the  activity.  MIS  also  supplies 
reports  to  upper  levels  of  the  Management  Subsystem  to  assist  with  system  per- 
formance evaluation. 

Additionally,  MIS  maintains  a data  base  of  operational  and  cost  data  per- 
tinent to  NTIPS  activities,  a configuration  index  describing  the  TM  requirements 
for  its  activity,  and  a history  file  on  user  feedback  report  actions  taken. 

Practices  and  Procedures  Subfunction  - This  subfunction  provides  for  gener- 
ating the  practices  and  procedures  of  the  operations  function  and  for  a library  func- 
tion to  control  and  disseminate  this  type  of  information.  These  practices  and  pro- 
cedures provide  detailed  operating  instructions,  based  on  the  first-level  policies,  for 
use  by  the  operations  activity  to  procure  and  produce  its  TM  products. 

Feedback  and  Update  Subfunction  - This  subfunction  provides  a viable,  cen- 
tral feedback  point  close  to  the  user  that  is  reactive  to  all  user  feedback  reports. 
This  subfunction  is  also  responsible  for  controlling  out-of-production  TM  updates. 

All  user  feedback  reports  (FBRs)  are  evaluated,  prioritized,  assigned  to 
a responsible  performing  activity,  and  tracked  until  a solution  is  provided.  The 
quality  of  delivered  TMs  is  evaluated  by  analyzing  all  quality-related  user  FBRs. 

In-production  TM  updates  are  initiated  by  the  hardware  acquisition  manager, 
but  because  this  position  does  not  exist  for  out-of-production  equipment,  the  feed- 
back and  update  subfunction  is  responsible  for  initiating  out-of-production  TM  up- 
dates. Once  initiated,  all  TM  updates  use  the  same  process  as  new  TM  acquisitions 
to  provide  the  TM  product. 
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Configuration  Accounting  Subfunction  - This  subfunction  provides  for  a 
TM  configuration  index  of  the  requirements  for  each  major  acquisition  activity. 

The  data  base  for  configuration  accounting  will  be  a part  of  the  information  stored 
in  MIS.  This  subfunction  will  compile  and  format  the  data  so  as  to  show  the  number 
of  TMs  needed,  the  requirements  of  each  user,  and  the  number  of  TMs  stored  for 
user  TM  replenishment. 

The  configuration  accounting  subfunction  will  assign  control  numbers  to 
TMs  in  accordance  with  policies  established  by  the  first-level  NTIPS  management 
function.  The  subfunction  will  establish  proper  levels  of  user  replenishment  stock 
at  the  Distribution  Subsystem  to  meet  user  needs.  This  subfunction  also  provides 
guidelines  for  storage  and  maintenance  of  the  TM  master  file  of  all  active  and  in- 
active TMs  stored  by  the  Distribution  Subsystem. 

Cost  Monitor/Evaluation  Subfunction  - The  cost  monitor/evaluation  sub- 
function provides  a controlled,  comprehensive  monitoring  system  of  NTIPS  costs 
and  operations.  This  subfunction  establishes  the  requirements  for  monitoring  the 
different  activities  of  NTIPS.  From  these  requirements,  the  practices  and  pro- 
cedures subfunction  prepares  detailed  monitoring  procedures  that  are  disseminated 
by  the  NTIPS  Operations  Management  Subfunction  to  the  various  NTIPS  subsystems. 

This  subfunction  receives  a quarterly  report  from  MIS  that  provides  a costs/ 
operations  summary  of  all  in-process  programs.  This  information  is  used  to  evalu- 
ate the  progress  of  the  TM  program,  identify  any  problem  trends,  and  recommend 
any  solutions  to  potential  problems. 

TABLE  4-16.  NTIPS  OPERATIONS  MANAGEMENT  FUNCTION 


NTIPS  Operation  • Coordinate  NTIPS  activities 

Management  Subfunction  • Evaluate  NTIPS  activities 

• Control  TM  funding 

• Review  staffing  and  budgeting 

• Promulgate  detailed  operating  procedures 

• Maintain  cost  data  base 

• Maintain  TM  configuration  index 

• Maintain  feedback  action  data  base 

• Prepare  and  distribute  weekly  management 
information  reports 

• Respond  to  information  requests 

• Prepare  detailed  NTIPS  procedures 

• Maintain  practices  and  procedures  manual 

• Maintain  policies/directives  manual 

• Maintain  TM  configuration  index 

• Establish  user  TM  replenishment  stock  level 

• Manage  TM  numbering  system 

• Guidance  for  TM  master  storage  procedures 

Feedback  and  Update  • Manage  user  feedback  systems 

Subfunction  • Initiate  out-of -production  TM  updates 

• Evaluate  quality  of  delivered  TMs 

Cost  Monitor/Evaluation  • Establish  TM  cost  data  base 

Subfunction  • Monitor  schedule/budget  of  NTIPS  activities 

• Evaluate  TM  cost/schedule  performance 

• Recommend  cost  improvements 


Management  Information 
System  Subfunction 


Practices  and  Procedures 
Subfunction 


Configuration  Accounting 
Subfunction 
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4.5.4  SUPPORT  OF  OPERATIONS  THROUGH  THE  NTIPS  MANAGEMENT  INFORMATION 
SYSTEM  (MIS) 

The  NTIPS  Management  Information  System  is  an  automated  information  repository 
that  provides  reports  to  three  management  levels  to  support  the  daily  operations  of 
NTIPS  and  to  aid  system  performance  evaluation 

An  MIS  would  be  established  in  each  of  the  dedicated  NTIPS  operations 
management  functions  that  would  contain  information  that  pertains  to  only  its  own 
major  acquisition  activity.  As  shown  in  Figure  4-24,  the  NTIPS  subsystems  input 
cost  and  operational  data  directly  into  the  MIS  using  procedures  established  by  the 
cost  monitor/evaluation  subfunction. 

Cost  and  performance  information  reports  are  required  on  three  levels  to 
operate  an  NTIP  System.  The  MIS  will  prepare  these  reports  and  disseminate  them 
according  to  procedures  established  by  the  NTIPS  Operations  Management  Subfunc- 
tion. The  three  reports,  described  below,  will  require  differing  amounts  of  proc- 
essing to  produce  the  levels  of  information  needed. 

The  MIS  reports  that  support  the  daily  operations  of  the  NTIP  Subsystem 
are  prepared  and  delivered  weekly  and  contain  the  detailed  information  needed  by 
the  function  (or  subsystem)  operators  and  managers.  This  information  includes  a 
breakdown  of  costs  incurred  versus  budget  dollars  versus  schedule  milestones.  This 
level  of  data  is  essential  in  the  day-to-day  management  of  an  operation. 

MIS  sends  a second  report  on  a quarterly  basis  to  the  cost  monitor/evaluation 
subfunction  in  the  Operations  Management  Subfunction.  This  report  provides  a 
summary  of  all  cost  and  performance  information  for  the  TM  programs  under  con- 
tract for  a major  acquisition  activity.  These  reports  will  be  used  to  evaluate  the 
progress  of  these  programs,  identify  potential  problem  trends,  and  recommend 
problem  solutions. 

The  third  type  of  report  is  a semiannual  (or  annual)  summary  for  the  NTIP 
Systems  management  function.  This  report  will  summarize  cost  and  performance 
of  all  TM  programs  and  related  activities  of  each  major  acquisition  activity.  These 
reports  will  be  used  for  in-depth  studies  and  overall  evaluation  of  the  performance 
of  the  NTIP  System. 

The  MIS  also  will  contain  a TM  configuration  data  base  that  is  controlled 
by  the  configuration  accounting  subfunction.  A listing  of  all  the  TMs  stored  in  the 
Distribution  Subsystem,  plus  a listing  identifying  the  TMs  assigned  to  and  being  used 
by  each  user  will  be  maintained  by  MIS.  This  data  base  is  used  mainly  by  the  TM 
Acquisition  Subsystem  and  the  Distribution  Subsystem  to  establish  distribution  re- 
quirements and  prepare  shipping  labels.  A summary  of  operations  will  be  sent  an- 
nually to  the  first-level  NTIPS  management  function. 

MIS  also  would  be  used  by  the  feedback/update  subfunction  to  store  a list- 
ing of  all  received  user  feedback  reports.  The  information  listed  is  the  action  taken 
on  each  report,  the  time  required  for  any  problem  solution,  and  the  disposition  of 
the  solution.  An  analysis  of  this  user  feedback  data  by  the  first-level  NTIPS  man- 
agement function  on  an  annual  basis  can  reveal  problems  with  TM  quality  and  also 
provide  an  evaluation  of  the  effectiveness  of  the  user  feedback  system. 

The  MIS  also  would  be  used  by  the  feedback/update  subfunction  to  store 
a data  base  of  TM  update  information.  This  information  includes  the  status  of  all 
in-process  TM  change  programs,  a list  of  all  TMs  needing  changes,  and  a priority 
file  indicating  the  TMs  most  urgently  needing  updating.  This  information  will  be 
sent  annually  to  the  first-level  management  function  and  can  be  utilized  to  assist 
with  long  range  planning  and  to  evaluate  the  effectiveness  of  the  TM  updating 
system. 
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4.5.5  DESCRIPTION  OF  THE  CENTRALIZED  NTIPS  MANAGEMENT  SUBSYSTEM 
ALTERNATIVE 

In  the  Centralized  NTIPS  Management  Subsystem  alternative,  policies  and  guidance 
are  established  at  a first-management  level  NTIPS  management  function,  with  a single 
second-level  NTIPS  operations  management  function  to  provide  detailed  operating 
procedures  and  support  to  the  NTIPS  activities  procuring  and  producing  TMs. 

As  shown  in  Figure  4-25,  the  centralized  alternative  uses  a two-level  struc- 
ture for  the  NTIPS  Management  Subsystem,  as  does  the  preliminary  system  concept. 
Also,  the  internal  structure  at  each  level  of  management  is  the  same  for  both 
subsystem  designs. 

The  only  major  difference  between  the  two  choices  is  with  the  number 
of  second-level  NTIPS  operations  management  functions  required  to  support  the 
TM  procurement  and  production  activities.  The  centralized  alternative  design 
uses  only  one  combined  second-level  management  function,  while  the  preliminary 
subsystem  concept  design  provides  a dedicated  second-level  NTIPS  operations 
management  function  to  each  major  acquisition  activity. 

The  main  advantage  of  using  the  centralized  alternative  is  its  simplification 
of  the  overall  NTIPS  management  structure.  The  centralizing  of  the  second-level 
management  functions  improves  system  performance  by  eliminating  the  redundancj 
of  multiple  management  functions  and  the  resulting  dispersal  of  Navy  TM  management. 
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PRELIMINARY  CONCEPT 


CENTRALIZED  ALTERNATIVE 


Figure  4-25.  Centralized  Management  Structure  Comparison.  The  real  difference  between  the 
structures  is  that  in  the  alternative  only  a single  operations  management  function  is  needed  to 
support  the  procurement  and  production  of  TMs  for  all  major  acquisition  activities. 
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4.5.6  DESCRIPTION  OF  DECENTRALIZED  NTIPS  MANAGEMENT  SUBSYSTEM 
ALTERNATIVE 

The  decentralized  Management  Subsystem  alternative  expands  responsibilities  of 
existing  organizations  and  establishes  a new  NTIPS  advisory  function  at  the  Navy- 
wide level.  The  responsibility  for  operating  the  NTIP  System  is  distributed  to  second- 
level  NTIPS  operations  management  functions  situated  in  each  major  acquisition 
activity. 

As  shown  in  Figure  4-26,  one  of  the  major  differences  between  the  decen- 
tralized alternative  and  the  preliminary  concept  is  at  the  first  management  level. 
The  preliminary  concept  NTIPS  management  function  is  responsible  for  the  oper- 
ations of  NTIPS,  while  the  decentralized  alternative  NTIPS  advisory  function  acts 
as  an  advisor  to  Navy-wide  management  on  TM  matters.  The  function  would  also 
serve  as  TM  representative  in  high-level  coordination  with  the  Navy,  DoD,  and 
industry.  This  function  also  would  monitor  the  operations  of  NTIPS  and  makes 
recommendations  to  Navy-wide  management  to  assist  with  long-range  planning. 

A second  major  difference  between  the  two  NTIPS  designs  is  the  relocating 
of  the  research  and  development,  system/product  improvement  engineering,  and 
cost  analysis/forecasting  subfunctions  to  each  of  the  second-level  operations  man- 
agement functions.  This  shift  reduces  the  responsibilities  of  these  subfunctions 
from  a Navy-wide  basis  to  the  major  acquisition  activity  level.  The  other  subfunc- 
tions at  the  decentralized  second-level  are  the  same  as  in  the  preliminary  concept, 
except  that  the  cost  monitor/evaluation  responsibilities  are  combined  into  the 
responsibilities  of  the  cost  analysis/forecasting  subfunction. 

The  main  advantage  of  the  decentralized  subsystem  design  is  minimal 
organizational  disruption  during  system  implementation.  This  advantage  is  the 
result  of  being  able  to  expand  existing  organizations  instead  of  performing  a major 
reorganization  of  existing  structures. 


I 

I 


Figure  4-26.  Decentralized  Management  Structure  Comparison.  The  decentralized  alternative  differs 
from  the  preliminary  concept  in  concentrating  management  functions  at  the  major  acquisition  activity, 
leaving  an  advisory  management  function  at  the  system  level. 
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5.1  PLANS  FOR  PERFORMANCE  EVALUATIONS  OF  PRELIMINARY  CONCEPT  AND 
ALTERNATIVES 

Task  4 will  evaluate  three  system  alternatives  developed  along  cost/design  risk  guide- 
lines. These  alternatives  will  be  evaluated  in  terms  of  performance  of  the  main  system 
functions. 


The  next  tasks  to  be  accomplished  in  NTIPP  Phase  1 are  the  Concept  Re- 
finement and  Performance  Tradeoff  Analysis  (Task  4),  and  Cost/Effectiveness  Anal- 
yses (Task  5).  These  tasks  will  examine  the  preliminary  system  concept  and  alterna- 
tives in  light  of  currently  available  data  concerning  performance  and  cost. 

The  performance  evaluation  in  Task  4 will  consist  of  the  following  steps 
(see  Figure  5-1): 

• Perform  subsystem/functional  alternative  tradeoffs. 

• Synthesize  three  alternative  cost/risk  levels  of  the  system  concept. 

• Conduct  a functional  performance  analysis  of  each  of  the  three  versions 
of  the  concept. 

• Document  the  results  of  the  analysis  in  matrix  form  for  ease  of  reference 
in  subsequent  cost  effectiveness  analysis. 

The  variety  of  possible  NTIPS  functional  designs  is  large  and  complex,  con- 
sidering the  entire  process  of  creating  a technical  manual  from  the  engineering 
and  logistic  data  base  through  the  distribution  of  the  finished  TM  product.  If  one 
were  to  evaluate  all  the  possible  system  combinations  of  alternatives  identified 
in  this  report,  the  scope  of  an  effectiveness  and  cost  analysis  would  become  enor- 
mous. The  concept  of  constructing  three  system  level  alternatives  using  cost/risk 
guidelines  provides  a solution  to  this  problem. 

Prior  to  definition  of  the  system  cost/risk  alternatives  however,  performance 
tradeoffs  will  be  accomplished  on  the  subsystem/functional  alternatives,  since  most 
are  independent  of  other  system  level  considerations.  This  will  help  define  an  opti- 
mum performance  system,  and  ensure  that  all  functional  eilternatives  are  examined 
in  terms  of  performance,  whether  or  not  they  are  utilized  in  one  of  the  three  alter- 
native cost/ risk  level  systems. 

In  defining  alternative  system  versions,  both  cost  levels  and  degree  of  design 
risk  will  be  used  as  guidelines.  Thus,  the  guideline  for  structuring  the  "bare  bones" 
system  will  be  that  of  a minimum-cost  system  meeting  basic  mission  requirements. 
Because  definitive  system  costs  will  not  be  developed  until  Task  5,  minimum  cost 
will  be  interpreted  here  as  a relative  rather  than  an  absolute  measure.  The  guide- 
line used  for  developing  a second  system  alternative  will  be  that  of  maximized  per- 
formance using  available  technology.  The  third  system  alternative  will  be  con- 
structed using  maximized  performance,  with  risk  technology  as  the  basic  guideline. 

It  should  be  noted  here  that  the  intent  is  not  to  select  the  ultimate  NTIP  System 
strictly  from  these  three  cost/risk  alternatives.  The  cost/risk  guidelines  simply 
provide  a context  in  which  to  conduct  the  system  performance  and  cost  evaluations. 

The  performance  analysis  in  Task  4 will  employ  detailed  effectiveness  cri- 
teria at  the  function  level.  While  hardware  systems  are  evaluated  largely  in  terms 
of  measures  of  effectiveness  (MOE),  the  NTIP  System  includes  many  nonparametric 
design  concepts.  Therefore,  the  NTIPS  set  of  effectiveness  criteria  will  include 
features  of  effectiveness  (FOE)  as  well  as  MOE.  Although  the  application  of  FOEs 
in  matrix  comparisons  will  not  be  quantitative  in  the  sense  that  they  will  be  weighted 
and  summed,  the  FOEs  will  provide  a basis  for  ordinal  ranking  of  alternatives. 

Rationale  will  be  provided  to  support  the  performance  evaluation  matrices. 
This  rationale  will  provide  the  data  and  logical  processes  leading  to  the  results  shown 
in  the  matrices. 
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In  accomplishing  the  performance  evaluation,  significant  gaps  in  the  data 
base  may  be  identified.  Opportunities  for  capture  of  data  needed  for  confirmation 
of  the  Phase  I system  tradeoffs  during  Phase  II  will  be  identified. 


Figure 
at  the 


5-1.  Performance  Evaluation  Process.  The  results  of  Task  4 will  be  recorded  in  matrix  form 
function  level  to  enable  detailed  comparisons  between  alternatives. 
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5.2  PLANS  FOR  NTIPS  COST  ANALYSIS 


j The  critical  subject  of  NTIPS  costs  requires  careful  analysis  in  order  to  develop  con- 

clusions regarding  affordibility  and  cost-effectiveness.  This  cost  analysis  will  be  ac- 
complished in  NTIPP  Task  5. 

Intelligent  decisions  regarding  selection  of  the  NTIP  System  concept  must 
be  made  on  the  basis  of  cost  as  well  as  performance.  Having  accomplished  a per- 
formance evaluation  of  the  NTIP  System  cost/risk  alternatives  in  Task  4,  the  pur- 
pose of  Task  5 is  to  develop  cost  comparisons  of  the  three  system  alternatives. 

The  resulting  cost  estimates  will  be  recorded  in  matrix  form  for  ease  of  comparison 
with  the  performance  matrices  of  Task  4. 

The  cost  analysis  will  treat  the  system  cost/risk  alternatives  on  a function 
i by  function  basis  (see  Figure  5-2).  Cost  summaries  will  be  provided  at  both  the 

I system  and  subsystem  level.  Cost  will  be  analyzed  in  terms  of  investment  vs.  oper- 

ating costs  and  fixed  vs.  variable  costs.  Fixed  costs  are  those  which  result  from 
the  existence  of  an  NTIP  System  and  are  independent  of  load.  Variable  costs  are 
costs  which  depend  on  the  number  of  procurements,  number  of  TMs  produced,  etc., 
on  an  annual  basis. 

Previous  researchers  have  frequently  reported  difficulty  in  obtaining  reliable 
I and  objective  cost  data  for  technical  manuals.  Current  means  of  cost  collection 

do  not  lend  themselves  to  generation  of  a reliable  technical  manual  cost  data  base. 

! Furthermore,  cost  collection  techniques  differ  widely  throughout  the  responsible  Navy 

organizations.  The  success  of  NTIPP  cost  data  collection  efforts  to  date  has  been 
constrained  because  of  these  problems.  The  data  problem  is  most  evident 
in  those  areas  of  the  system  which  do  not  normally  involve  major  contractor  efforts 
(TM  Acquisition,  Distribution,  and  Management  Subsystems).  Consequently,  cost 
estimates  rather  than  hard  data  will  be  used  in  portions  of  the  analysis.  When  such 
estimates  are  made,  the  underlying  assumptions  will  be  provided. 

The  need  for  specific  data  not  currently  available  will  be  identified  in  the 
i report.  The  framework  of  the  analysis  will  be  such  that  future  cost  information  may 

^ be  readily  incorporated  in  the  analysis,  and  its  impact  quickly  evaluated. 

The  objective  of  both  the  performance  evaluation  task  and  the  cost  analysis 
task  is  to  provide  maximum  visibility  to  the  decision  makers.  When  these  tasks 
are  completed,  matrices  will  be  available  which  permit  direct  comparision  of  per- 
formance and  cost  of  the  three  alternative  NTIP  Systems  on  a function-by-function 
basis.  These  matrices  and  their  supporting  rationale  will  contain  the  facts,  knowl- 
edge, and  clearly  stated  assumptions  which  are  relevant  to  the  decisions  involved 
in  selecting  the  ultimate  NTIP  System  concept. 


TM  SPECIFICATIONS  FUNCTION 

INVESTMENT  COST 

OPERATING  COST 

COST  CATEGORIES 
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EQUIPMENT 
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Figure  5-2.  Cost  Analysis  Reporting  Matrix.  The  Task  5 cost  summaries  will 
report  estimated  investment  and  operating  costs  for  the  function  (shown  above), 
subsystem,  and  system  level  for  each  of  three  system  level  alternatives. 
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CiLOSSAii\  OB  ABBREVIATIONS  AND  ACRONYMS 
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Abbreviation 
or  Acronym 

Full  Terminology 

A 

AC  FT 

Aircraft 

ACN 

Advance  Change  Notice 

A DP 

Automatic  Data  Processing 

A DP REPS 

Automated  Document  Preparation  System 

AFf 

Air  Force  Base 

AFllRL 

Air  Force  Human  Resources  Laboratory 

A FIT 

Air  Force  Institute  of  Technology 

aflc 

Air  Force  Logistics  Command 

AFPRO 

Air  Force  Plant  Representative  Office 

A FSC 

Air  Force  Systems  Command 

AGSP 

Automated  Graphic  Science  Program 

AlA 

Aerospace  Industries  Association 

AIDUS 

Automated  Input  and  Document  Update  System 

ALC 

Air  Logistics  Center 

ARl 

Automated  Reading  Index 

ARMCOM 

Armament  Command 

ASCII 

American  Standard  Code  for  Information  Interchange 

ASL 

Average  Sentence  Length 

ATE 

Automatic  Test  Equipment 

ATOS 

Automated  Technical  Order  System 

ATS 

(1)  Administrative  Terminal  System 

AUTO  DIN 

(2)  Aircraft  Troubleshooting  System 

Automatic  Digital  Information  Network 

AUTOTEC 

Automated  Text  Composition 

AVSCOM 

Aviation  System  Command 

AWL 

Average  Word  Length 

B 


I 

i 


\ 


13  A MAC  AT 
BFIC 
BITE 
BUM  El) 
BUPERS 


Block-A-,Vlatic,  Block- A-Grain,  Block-A-Text 

Binary  Fault  Isolation  Chart 

Built-In  Test  Equipment 

Bureau  of  Medicine 

Bureau  of  Naval  Personnel 
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Abbreviation 
of  Acronym 


I 


Full  Terminology 
C 


CAD 

CAM 

CCD 

CDRL 

CEiVl 

CFA 

CFAE 

CF/TA 

CFE 

CG 

CIC 

CNET 

CNETSCPAC 

CNM 

CNTT 

COM 

COMSAT 

CONSD 

CRC 

CRT 

CTA 


Computer-Aided  Desi^ 

Computer-Aided  Manufacture 
Charged-Coupled  Device 
Contract  Data  Requirements  List 
Communications,  Electronics,  Meteorology 
Cognizant  Field  Activity 
Contractor-Furnished  Aeronautical  Equipment 
Cognizant  Field/Technical  Activity 
Contractor-Furnished  Equipment 

(1)  Content  Generation 

(2)  Commanding  General 
Combat  Information  Center 

Chief  of  Naval  Education  and  Training 

Chief  of  Naval  Education  Training  Service  Support  Center  Pacific 

Chief  of  Naval  Materiei 

Chief  of  Naval  Technical  Training 

Computer  Output  Microform 

Commercial  Satellite  System 

Condensed  Service  Data 

Command  and  Reporting  Center 

Cathode  Ray  Tube 

Cognizant  Technical  Activity 


D 


DA 

DAPIL 

DAR 

DARCOM 

DCAS 

DCS/LOG 

DDD 

DID 

DIODS 

DLAO 

DMAAC 

DMWR 

DoD 

DR 

DTNSRDC 


Department  of  the  Army 
Digital  Assembly  Parts  Identification  List 
Data  Automation  Requirement 
Development  and  Readiness  Command 
Defense  Contract  Administration  Service 
Deputy  Chief  of  Staff  for  Logistics 
Direct  Distance  Dialing 
Data  Item  Description 
Diagram-Oriented  Documentation  System 
Defense  Logistics  Analysis  Office 
Defense  Mapping  Agency  Aerospace  Center 
Deferred  Maintenance  Work  Request 
Department  of  Defense 

(1)  Deficiency  Report 

(2)  Discrepancy  Report 

David  Taylor  Naval  Ship  Research  and  Development  Center 


E 


ECN 

ECOM 

ECP 

EPC 

EO 

ETM 


Engineering  Change  Notice 
Electronics  Command 
Engineering  Change  Proposal 
Editorial  Processing  Center 
Engineering  Order 
Extension  Training  Material 
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A 


Abbreviation 
of  Acronym 


F 


FBK 

FIPS 

FLISATCOM 

FOE 

FOM.M 

FORCASl 

FPUPA 

FPTA 


GAF 

GAPFlbEE  It 
(JATF 
or  r 
GL 

GOCO 
GOM 
GPA  vi 
GPO 


HQ 

HRMR 


IB  vl 

ICBVl 

10 

IL5 

IPU 

IPR 

ri'DT 


JCP 

JPA 

JPM 


LCC 

LDM 

LSA 


Feedback  Report 

Federal  Information  Processing  Standard 

Fleet  Satellite  Communications 

Features  of  Effectiveness 

Functionally  Oriented  Maintenance  Manual 

Fox,  FORd,  CAylor,  STicht 

Fully  Proceduralized  Job  Performance  Aid 

Fully  Proceduralized  Troubleshooting  Aid 


G 


German  Air  Force 

DoD  program  name 

Graphic  Arts  Technical  Foundation 

General  Classification  lest 

Grade  Level 

Government-Owned,  Contractor-Operated 
Graphic  Operations  Alanual 

Graphically  Proceduralized  Aids  for  Maintenance 
Government  Printing  Office 

H 


Headquarters 

Human-Readable/Machine-Readable 

I 

(1)  Intermediate  Ballistic  Missile 

(2)  International  Business  Machines 
Intercontinental  Ballistic  Missile 
Identification 

Integrated  Logistic  Support 
Illustrated  Parts  Breakdown 
In-Process  Review 

Improved  Technical  Documentation  and  Training 

J 

Joint  Committee  on  Printing 
Job  Performance  Aid 
Job  Performance  Manual 

L 


Ijfe  Cycle  Cost 

Local  Digital  Message  Exchange 
Logistic  Support  Analysis 
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Abbreviation 

of  Acronym  Full  Terminology 

M 


MA 

MAC 

MARIS  AT 

MDC 

MDS 

MEA 

MECH 

MIARS 

MICOM 

MICROFORM 

MIP 

MIS 

MMC 

MOE 

MOS 

MPL 

MRC 

MT/SC 

MT/ST 


Maintenance  Action 

Maintenance  Allocation  Chart 

Maritime  Mobile  Satellite  Communication  System 

Maintenance  Dependency  Chart 

Maintenance  Data  System 

Maintenance  Engineering  Analysis 

Mechanical  Comprehension 

Maintenance  Information  Automated  Retrieval  System 
Missile  Command 

A process  for  reproducing  printed  matter  in  a much  reduced  size 

(1)  Maintenance  Index  Pages 

(2)  Material  Improvement  Project 
Management  Information  System 
Maintenance  Management  Center 
Measures  of  Effectiveness 
Military  Occupational  Specialty 
Maintenance  Parts  List 
Maintenance  Requirement  Card 
Magnetic  Tape  Selectric  Composer 
Magnetic  Tape  Selectric  Typewriter 


N 


NAMP 

NARF 

NATSF 

NAVAIR 

NAVCOMPARS 

NAVELEX 

NAVFAC 

NAVMACS 

NAVMAT 

NAVSEA 

NAVSUP 

NC 

NDCP 

NEC 

NEOCS 

NMA 

NOTAP 

NPFC 

NPPSBO 

NPPSO 

NPPSMO 

NPRDC 

NRL 

NSA 

NSDSA 


Naval  Aviation  Maintenance  Program 
Naval  Air  Rework  Facility 
Naval  Air  Technical  Services  Facility 
Naval  Air  Systems  Command 

Naval  Communication  Processing  and  Routing  System 
Naval  Electronic  Systems  Command 
Naval  Facilities  Command 

Naval  Modular  Automated  Communications  System 

Naval  Material  Command 

Naval  Sea  Systems  Command 

Naval  Supply  Systems  Command 

Numerical  Control 

Navy  Decision  Coordinating  Paper 

Navy  Enlisted  Classification 

Navy  Enlisted  Occupational  Classification  System 

National  Micrographics  Association 

Navy  Occupational  Task  Analysis  Program 

Navy  Publications  and  Forms  Center 

Naval  Publications  and  Printing  Services  Branch  Office 

Naval  Publications  and  Printing  Services  Office 

Naval  Publications  and  Printing  Services  Management  Office 

Naval  Personnel  Research  and  Development  Center 

Naval  Research  Laboratory 

National  Security  Agency 

Naval  Ships  Data  Support  Activity 
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Abbreviation 

of  Acronym  Full  Terminology 


NSF 

NSVVSFS 

NTIP 

M'lPH 

NTIPS 

NTMMO 

Nl'iVlS 

NWC 


National  Science  Foundation 

Naval  Ship  Weapon  Systems  Engineering  Station 

Navy  Technical  Information  Program 

Navy  technical  Information  Presentation  Program 

Navy  Technical  Information  Presentation  System 

Navy  Technical  \lanual  Management  Organization 

Navy  Technical  Manual  System 

Naval  Weapons  Center 


O 


OCALC 

OCR 

OJT 

OMB 

O&MN 

OP  ALT 

OPNAV 

ORDALT 

OSD 


Oklahoma  City  Air  Logistics  Center 

Optical  Character  Recognition 

On-the-Job  Training 

Office  of  Management  and  Budget 

Operation  and  Maintenance,  Navy  (funding) 

Operational  Alteration 

Office  of  the  Chief  of  Naval  Operations 

Ordnance  Alteration 

Operational  Sequence  Diagram 

P 


PI  A 

PIMO 

PM 

PMS 

PO 

PPS 

PPT 

PQS 

PRAM 

PRMIS 

PYRAGRAM 


QA 

QC 

QRC 

QRTMMS 


Printing  Industries  of  America 

Presentation  of  Information  for  Maintenance  and  Operation 

Program  Manager,  or  Project  Manager 

Planned  Maintenance  System 

Program  Office,  or  Project  Office 

Percent  Personal  Sentences 

Punched  Paper  Tape 

Personnel  Qualifications  Standard 

Programmable  Random  Access  Memory 

Printing  Resources  and  Management  Information  System 

Pyramid  of  Diagrams 


Q 


Quality  Assurance 

Quality  Control 

Quick  Reaction  Capability 

Quick  Reaction  Technical  Manual  Modification  System 

R 


RAC 

RCA 

R3fD 

RDT(5cE 

RE 

RGL 

RFP 

RIDE 


Rapid  Action  Change 

Radio  Corporation  of  America 

Research  and  Development 

Research,  Development,  Test,  and  Evaluation 

Reading  Ease 

Reading  Grade  Level 

Request  for  Proposal 

Reading  Impact  Difficulty  Estimate 
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Abbreviation 
of  Acronmy 


SAP 

SECNAV 

SECNAVINST 

SFTOA 

SIMM 

SHIPALT 

SMMD 

SMS 

SOM 

SORTS 

SOW 

SPO 

SRI 

STEDMIS 

STEPS 

STOP 

SURTASS 

SYSCOM 


TACFIRE 

TACSAT 

TAEG 

TAG 

TAMMS 

TCTO 

TEC 

TIM 

TIP 

TM 

TMCR 

TMDER 

TMINS 

TMIP 

TMMP 

TMMPC 

TMSR 

TMSS 

TO 

TOIRS 

TOMA 

TOMS 

T/R 

TRADOC 

TRUMP 

T/TM 


Full  Terminology 
S 

System  Acquisition  Process 
Secretary  of  the  Navy 
Secretary  of  the  Navy  Instruction 
Systems  and  Feasibility  Tradeoff  Analysis 
Symbolic  Integrated  Maintenance  Manual 
Ship  Alteration 

Simplified  Maintenance  Manual  Design 

Surface  Missile  System 

Simplified  Operations  Manual 

Shipboard  Organizational  Troubleshooting  System 

Statement  of  Work 

System  Program  Office 

Stanford  Research  Institute 

Ships  Technical  Data  Management  Information  System 
Ships  Technical  Publications  System 
Sequential  Thematic  Organization  of  Publications 
Surveillance  Towed  A^ray  Sonar  Segment 
Systems  Command 


T 

Tactical  Fire  Direction  System 
Tactical  Satellite 

Training  Analysis  and  Evaluation  Group 
The  Adjutant  General 

The  Army  Maintenance  Management  System 
Time  Compliance  Technical  Order 
Training  Extension  Course 
Task  Identification  Matrix 
Technical  Information  Presentation 
Technical  Manual 

Technical  Manual  Contract  Requirement 
Technical  Manual  Deficiency  Evaluation  Report 
Technical  Manual  Identification  Numbering  System 
Technical  Manual  Improvement  Program 
Technical  Manual  Management  Program 
Technical  Manual  Management  Program  Council 
Technical  Manual  Seatask  Requirement 
Technical  Manual  Specifications  and  Standards 
Technical  Order 

Technical  Order  Improvement  Reporting  System 
Technical  Order  Management  Agency 
Technical  Order  Microfilm  System 
Troubleshooting  and  Repair 
Training  and  Doctrine  Command 

Technical  Review  and  Update  of  Manuals  and  Publications 
Training/Technical  Manual  (tradeoff) 
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Abbreviation 
of  Acronmy 


UR 

US 

USDA 

USAF 

USAMC 

USA.VIMC 

USANUL 


VDT 


Full  Terminology 
U 


Unsatisfactory  Report 
United  States 

United  States  Department  of  Agriculture 

United  States  Air  Force 

United  States  Army  Materiel  Command 

United  States  Army  Maintenance  Management  Center 

United  States  Army  Nuclear  Defense  Laboratories 

V 

Visual  Display  Terminal 
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DEFINITIONS  OF  NTIPP  TERMS 


Accessibility 


Archive 


Comprehensibility 


Content  Generation 


Content  Generator 


Component 


Dedicated  Function 


The  characteristics  of  a TM  which  enable  the 
user  to  find  the  information  he  is  seeking  quickly. 
Methods  of  partitioning  the  TM,  indexing  its  con- 
tents, and  numbering  and  paginating  are  all  sub- 
jects for  accessibility  improvements. 

In  the  NTIPS  concept,  the  repository  for  TM 
masters.  The  archive  function  has  two  subfunc- 
tions, historical  and  working,  and  would  have 
capabilities  for  storage,  retrieval,  and  control 
of  the  masters. 

The  property  of  textual  information  that  permits 
it  to  be  readily  understood.  No  satisfactory 
means  of  measuring  this  property  is  available 
yet,  since  it  is  due  to  a complex  mixture  of  little 
understood  factors  such  as  word  familiarity  and 
concreteness,  complexity  of  syntactic  structures, 
rhetorical  devices,  clarity  of  reasoning,  courtesy 
of  the  author,  etc. 

Transformation  of  engineering/manufacturing/ 
maintenance  data  bases  into  technical  inform- 
ation. This  includes  collecting  data,  planning, 
writing,  critiquing,  and  validating  the  TM. 

Contractor,  Navy  activity,  or  data  house  that 
performs  Content  Generation  activity. 

An  indenture  level  of  the  NTIP  System  config- 
uration that  is  below  the  subfunction  level. 

An  NTIPS  function  that  operates  under  the  NTIPS 
organizational  structure  to  provide  customized 
TM  services  for  a major  acquisition  activity. 


Digital  Production 


In  the  NTIPS  concept  the  Publishing  function 
that  processes  the  Contractor's  delivered  TM 
information  (in  the  form  of  magnetic  digital 
tape)  for  ultimate  mastering  and  replication. 

Distribution  An  operational  function  of  the  entire  TM  life- 

cycle  process  that  includes  assignment  of  docu- 
ment numbers,  distribution  of  TMs  and  updates, 
and  archival  storage. 

The  engineering  drawings,  reports,  and  related 
information  created  for  the  design  and  manu- 
facture of  a system/equipment.  This  information 
is  also  the  traditional  data  base  from  which  the 
TM  is  developed.  In  the  NTIPS  concept  the  data 
base  would  be  augmented  by  requiring  the  addi- 
tion of  maintenance  data. 

Feature  of  Effectiveness  (FOE)  Nonparametric  design  objective,  such  as  inform- 
ation quality,  task  relevance,  and  comprehen- 
sibility. 

Feedback  Information  from  the  TM  user  indicating  errors, 

omissions,  ambiguities,  or  other  deficiencies 
in  TMs. 


Engineering/Manufacturing 
Data  Base 


Function  An  indenture  level  of  the  NTIP  System  config- 

uration that  is  below  the  subsystem  level. 

Hard  Copy  TMs  printed  on  paper  (as  opposed,  for  example, 

to  video  disc). 


In-Production 

Major  Acquisition  Activity 


Management  Information 
System  (MIS) 


Equipment  that  is  currently  being  manufactured. 

An  activity  that  procures  systems/equipments, 
for  example,  NAVSEA,  NAVAIR,  or  major  Pro- 
gram Office,  such  as  TRIDENT  (PMS  396)  or 
(392)  CVN,  (393)  SSN. 

An  automated  repository  of  NTIPS  information 
covering  costs  and  operational  data,  a config- 
uration index  of  TM  users,  and  a history  of  user 
feedback  actions. 


Mastering  The  process  that  converts  the  TM  information 

output  of  the  content  generator  into  the  physical 
entity  needed  for  replication  of  the  TM. 

Measure  of  Effectiveness  (MOE)  A quantifiable  assessment  of  effectiveness. 

Media  Evaluation  Laboratory  A facility  established  and  maintained  for  the 

purpose  of  evaluating  the  effectiveness  and  util- 
ity of  media. 
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Medium  (pi.  Media) 


A means  of,  or  device  used  for,  conveying  or 
presenting  information. 


Microform 

Modular  Specifications 

Out-of-Production 

Production 

Publication  Tree 

Publishing 

Readability 


■•ny  one  of  several  applications  of  reduced-size, 
photographic  images  of  hard  copy.  Microfiche, 
a(x>rture  cards,  and  roll  (or  cartridge)  microfilm 
are  the  most  common  types  of  microforms. 

An  NTIPS  concept  that  provides  the  means  to 
custom-tailor  a TM  specification  to  a particular 
procurement  and  to  reduce  redundancy  and  ex- 
traneous information  in  the  specification.  Speci- 
fication modules  would  contain  precise  require- 
ments for  the  technical  content,  presentation 
techniques,  readability,  access,  publishing  proc- 
esses, and  quality  control  of  TMs. 

Equipment  that  is  no  longer  being  manufactured. 

Conversion  of  draft  technical  information  into 
final  TM  format. 

A diagram  illustrating  the  relationships  among 
technical  manuals  which,  collectively,  cover 
a given  system/equipment. 

The  total  process  for  taking  technical  information 
from  content  generators  and  recreating  it  as 
technical  manuals,  replicating  it,  and  delivering 
the  final  product  to  the  users. 

( 1)  Often  used  synonymously  with  "Comprehen- 
sibility," the  property  of  textual  information 
that  permits  it  to  be  readily  understood 

and  comprehended  in  the  ordinary  concep- 
tual sense.  Or, 

(2)  The  more  narrow  property  of  a text  that 
permits  it  to  be  easily  read  in  a grammatical 
sense,  as  measured  by  lexical  factors  such 
as  word  length  and  sentence  length.  Gram- 
matical readability  is  known  to  be  a good 
predictor  of  comprehension  performance. 

Or, 

(3)  The  readability  score  or  measurement  of 
a given  text  as  measured  by  some  formula 
of  various  lexical-grammatical  factors. 

The  absolute  value  of  this  score  can  be  cali- 
brated against  either  genres  of  documents 
or  school  grade  levels. 
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Reading  Grade  Level  (RGL) 


1 


r 


Replication 


Resupply 


Subfunotion 

Subsystem 


(1)  The  readability  measurement  of  a text, 
expressed  in  terms  of  equivalent  school 
grade  levels.  Or, 

(2)  The  reading  performance  level  of  a reader, 
expressed  in  terms  of  the  RGL  of  a standard 
text  that  he  has  com  prehended  to  a passable 
degree  (usually  50-75%  comprehension,  de- 
pending on  how  the  RGL  equivalence  of 

the  readability  formula  is  calibrated). 

The  process  that  provides  the  final  output  of 
the  Publishing  activity,  i.e.,  the  production  of 
the  TM  in  its  final  format  (e.g.,  paper  books, 
microform,  video  discs). 

A function  of  the  distribution  system  that  pro- 
vides TMs  in  response  to  specific  user  requests 
to  replace  damaged  or  last  TMs  previously 
supplied. 

An  indenture  level  of  the  NTIP  System  config- 
uration that  is  below  the  function  level. 

An  indenture  level  of  the  NTIP  System  config- 
uration that  is  below  the  system  level. 


Technical  Data  (TD)  The  source  data  contained  in  the  engineering/ 

manufacturing  and  LSA  data  bases  from  which 
technical  information  is  developed. 

Technical  Information  (TI)  The  writer-generated  material  developed  from 

technical  data.  Technical  information  is  sub- 
sequently converted  into  the  TM  by  production. 

Technical  Manual  (TM)  The  product  of  the  NTIP  System  which  contains 

the  operation,  maintenance,  and  training  informa- 
tion necessary  to  support  the  user  activity. 

TM  Acquisition  The  process  of  TM  procurement.  It  involves 

user-data  matching,  specification  selection, 
and  the  procurement  process. 

TM  Bookplan  A detailed  plan  for  development  of  the  TM  that 

goes  through  the  projected  TM  outline  at  the 
paragraph  level.  The  bookplan  provides  explicit 
direction  to  the  TM  writer,  including  examples 
of  the  technical  content  and  presentation  tech- 
nique as  required  by  the  TM  specification.  The 
bookplan  includes  scheduling  information  and 
plans  for  quality  assurance,  validation,  and  veri- 
hcation  of  the  resulting  TM  information. 
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TM  Development  Guide 

TM  Engineer 


Training/Technical  Manual 
Tradeoff 

User 

User-Data  Match 

User-Data  Match  Model 

Validation 

Verification 

Work  Package 


An  NTIPS  concept  for  a TM  engineer's  guide, 
which  supplements  instructions  contained  in 
TM  requirements,  that  would  provide  the  TM 
engineer  step-by-step  instructions  on  how  and 
when  to  accomplish  TM  development  tasks. 

(1)  Content  Generation  - A new  position,  created 
in  NTIPS,  that  is  assigned  responsibility 

for  planning,  initiating  and  supervising  all 
tasks  associated  with  content  generation. 

He  plans,  initiates  and  supervises  TM  devel- 
opment tasks  and  establishes  interrelation- 
ships with  design  engineering,  ILS,  and  QA 
activities. 

(2)  TM  Acquisition  - A new  position,  created 
in  NTIPS,  that  oversees  development  of 
TM  requirements,  delivery,  scheduling,  pro- 
posal and  contract  preparation,  quality  as- 
surance, budgeting  and  funding,  and  contract 
administration. 

Process  whereby  the  determination  is  made  as 
to  whether  information  is  to  be  presented  to 
a user  during  training  or  via  some  form  of  TM. 

Most  often,  the  maintenance  technician  or  sys- 
tem operator  who  will  actually  employ  the  TM 
within  a job  performance  context. 

Process  whereby  the  text  contents  and  present- 
ation techniques  for  technical  information  are 
matched  to  the  characteristics  and  requirements 
of  the  intended  user. 

The  means  by  which  user-optimized  presentation 
techniques,  related  to  his  personnel  character- 
istics, tasks,  and  working  environment,  are 
identified. 

Process  whereby  the  utility  of  technical  inform- 
ation is  established;  generally  performed  by 
the  content  generation  activity  and  witnessed 
by  the  procuring  activity. 

Process  whereby  the  accuracy  of  technical  inform- 
ation is  certified  in  the  field  under  simulated 
or  actual  job  conditions;  generally  performed 
by  procuring  activity. 

The  arrangement  of  technical  data  according 
to  functional  tasks. 
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Writers  Guide 


A guide  for  the  TM  writer  to  introduce  him  to  the 
NTIPS  system  and  provide  "how  to"  instructions 
on  new  techniques  of  presentation  and  readability. 
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APPENDIX  D 


DESCRIPTION  OF  SYSTEM  OPERATIONAL  SEQUENCE 


To  identify  and  test  the  interactions  between  the  major  NTIP  system  elements, 
functional  and  operational  sequence  diagrams  have  been  developed.  These  diagrams 
confirm  the  functional  configuration  and  operability  of  the  system. 

The  NTIPS  functional  sequence  diagrams  are  reproduced  in  Figures  D-1,  D-2, 
and  D-3.  These  diagrams  provide  a top  level  overview  of  the  main  interfaces  and 
interdependencies  among  major  NTIP  system  elements.  Five  main  functional  ele- 
ments of  the  NTIP  system  are  identified  at  the  top  of  the  diagrams.  Action  respon- 
sibilities are  represented  by  coded  symbols  and  descriptions  in  the  vertical  columns 
below  each  major  function.  System  interaction  and  functional  interfaces  are  trace- 
able horizontally  through  the  diagrams.  The  meaning  of  the  symbols  is  defined  in 
the  key  at  the  bottom  of  each  diagram. 

For  example,  a new  system  or  equipment  acquisition  sequence  is  introduced 
on  the  first  sheet  of  the  functional  sequence  diagram.  Figure  D-1.  A management 
action  to  allocate  funds  and  pass  responsibility  for  acquisition  and  procurement 
of  technical  manuals  to  the  responsible  system  subelement  is  depicted  in  the  first 
group  of  symbols.  Definition  of  operational  requirements  and  obtaining  a detailed 
description  of  the  new  system  are  shown  as  preliminaries  to  preparation  of  contrac- 
tual documents  at  the  outset  of  the  process. 

Operational  sequence  diagrams  describing  the  interplay  in  more  detail  are 
reproduced  in  Figures  D-2  and  D-3.  Figure  D-2  charts  continual  processes  within 
NTIPS,  while  Figure  D-3  details  the  operations  directly  involved  in  TM  development. 
In  these  more  detailed  diagrams,  brief  explanations  of  the  key  operations  performed 
in  response  to  typical  inputs  to  the  NTIP  system,  are  charted  in  the  vertical  columas. 
As  in  the  functional  sequence  diagrams,  symbols  and  descriptions  of  each  operation 
explain  the  activities  in  the  operational  sequence.  Communication  links  and  inter- 
play between  subfunctional  elements  are  traceable  horizontally  throughout  this 
series  of  diagrams. 

For  example,  a cycle  involving  technology  developments  impacting  on  the 
NTIP  system  is  charted  commencing  on  the  first  sheet  Figure  E-2.  This  is  one  to 
two  recurring  operational  cycles  depicted  as  continuing  processes,  to  which  the 
NTIP  system  must  be  responsive.  New  technology  information  originating  in  the 
military  services  or  industry,  is  shown  as  a key  input. 
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Figure  D-1.  NTIPS  Functional  Sequence  Diagram  (Sheet  1 of  3) 


Figure  0-1.  NTIPS  Functional  Sequence  Diagram  (Sheet  2 of  3) 
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Figure  D-1.  NTIPS  Functional  Sequence  I'hagram  (Sheet 
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Figure  D-3.  Operational  Sequence  Diagram  (Sheet  1 of  8) 
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D-3.  Operational  Sequence  Diagram  (Sheet  3 of  8) 
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Figure  D-3.  Operational  Sequence  Diagram  (Sheet  8 of  8) 


